search

qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.02k stars 38.74k forks source link

[Bug] BM60HSRGB_EC RGB keycodes not working #17998

Open Didel opened 2 years ago

Didel commented 2 years ago

Describe the Bug

The default layout for the BM60HSRGB_EC keyboard (BM60, Hotswap, RGB light, with rotary encoder) contains the usual RGB keycodes to control the RGB lightning. The default layout (see https://config.qmk.fm/#/kprepublic/bm60hsrgb_ec/rev2/LAYOUT ) implements the RGB_TOG, RGB_MOD, RGB_HUI, RGB_HUD, RGB_SAI, RGB_SAD, RGB_VAI and RGB_VAD keycodes on layer 1. However, none of them seem to work. The lights in the keyboard work fine: When plugging it in, the default pattern is visible and animates nicely from left to right in all colors of the rainbow. However, using the RGB_TOG key code (or any other of the RGB key codes mentioned above) do not make any difference.

They keys themselves work fine, the default layer correctly recognises the correct buttons being pressed (in fact, im typing on it right now). The layer switch also works fine, as I'm able to correctly use the F1-F12 buttons that are also on layer 1. So it seems to be that the key codes are correctly 'activated' but do not instruct the keyboard correctly to do something with the RGB output.

There is no customisation to the firmware, I use config.qmk.fm to compile the firmware (using the default layout) and then flash it to the keyboard using QMK Toolbox.

System Information

Keyboard: BM60HSRGB_EC Revision (if applicable): V2 Operating system: MacOS qmk doctor output: Not applicable

Any keyboard related software installed? No

sigprof commented 2 years ago

The kprepublic/bm60hsrgb_ec/rev2 keyboard is somewhat strange — it has two lighting options enabled at the same time:

RGBLIGHT_ENABLE = yes
RGB_MATRIX_ENABLE = yes

In this configuration the RGB keycodes control only the RGBLIGHT feature, which is used for underglow LEDs on that board. The default and via keymaps include custom keycodes which call rgb_matrix_*() functions to control the RGB Matrix feature (per-key LEDs); however, if you use the configurator, the code from the default keymap is not used, and therefore you end up with no way to control RGB Matrix.

For comparison, the kprepublic/bm60hsrgb/rev2 keyboard uses custom RGB Matrix driver code that combines per-key LEDs (using a LED controller chip) and underglow (addressable WS2812-compatible LEDs); in this configuration the RGB keycodes control the RGB Matrix feature (the RGBLIGHT feature is not enabled by default), and this works without any custom code in the keymap. However, in this configuration there is no way to enable only the per-key LEDs or only the underglow without adding some custom code.

Maybe the proper way to support configurator builds for those boards would be to move the custom keycodes to the keyboard level (however, that introduces some nastiness related to SAFE_RANGE).

Didel commented 2 years ago

Thank you for the reply! I think I understood most of that 😅 Does that mean that if I would compile the firmware myself using the default keymap, I should be able to control the backlight using the keycodes defined in the asdf-row of the default keymap?

Edit: In case any one wonders, the answer is: Yes! If you compile the firmware yourself, the default keycap will allow you to toggle the rib-matrix lights using the asdf-row 👍🏻