Feature Request Type
Description
The RGB matrix internally maps LEDs to a 224x64 matrix that is separate from the row/column switch/LED wiring matrix. While I can request the LED indices for a given wiring matrix row and then reconstruct the wiring matrix along with keycodes on the OpenRGB side with the existing protocol, this matrix does not always perfectly reflect the physical locations of the LEDs. Notably on my Q2, the arrow keys get shifted around such that one of them is out of place and RGB matrix effects generated by OpenRGB do not map correctly for the out of place key. Since QMK has the physical position data internally for its own built-in effects, it would be ideal if the Keychron RGB protocol provided a way to download these positions over USB so that external RGB software could also generate an accurate matrix. We implemented similar capability when we made the QMK OpenRGB protocol several years ago and VialRGB also implements something similar. Ideally this would be gated behind incrementing the Keychron RGB Protocol Version so software could optionally use the detailed position information on firmware that provides it or the basic wiring matrix position for firmware that does not.
Feature Request Type
Description
The RGB matrix internally maps LEDs to a 224x64 matrix that is separate from the row/column switch/LED wiring matrix. While I can request the LED indices for a given wiring matrix row and then reconstruct the wiring matrix along with keycodes on the OpenRGB side with the existing protocol, this matrix does not always perfectly reflect the physical locations of the LEDs. Notably on my Q2, the arrow keys get shifted around such that one of them is out of place and RGB matrix effects generated by OpenRGB do not map correctly for the out of place key. Since QMK has the physical position data internally for its own built-in effects, it would be ideal if the Keychron RGB protocol provided a way to download these positions over USB so that external RGB software could also generate an accurate matrix. We implemented similar capability when we made the QMK OpenRGB protocol several years ago and VialRGB also implements something similar. Ideally this would be gated behind incrementing the Keychron RGB Protocol Version so software could optionally use the detailed position information on firmware that provides it or the basic wiring matrix position for firmware that does not.