[Feature Request] Adaptive LED View for keyboards
Feature Request
The LED View, while useful for advanced users, is not exactly easy to use. Right now there's no directly indicated mapping between the LED grid, and the specific keys the LEDs map to, and there's no accounting for different key widths or shapes either. Basically it's a bit of a hit and miss to get a configuration right.
For this purpose I would like to recommend a mapping solution similar to what e.g. QMK uses - a configuration file (format to be decided) would be used in combination with the defined LEDs of a keyboard (or, in the future, any device, but for a first iteration, custom shaped and positioned zones are a bit of an overkill). This configuration file would describe each row of the keyboard as a list of key objects, holding the user-friendly representation (e.g. "esc", "caps lock", or a keycode), the LED ID assigned to that specific key (if there's any), and the size in the form of a two decimal float (so e.g. 1.5 for a tab key, 1.75 for caps lock, 2.0 for backspace, 3.0 for left shift, etc.). A small example, in pseudocode:
keyboard_layout_ansi = [
// Row 1
[ { key = "esc", led = "Keyboard LED 2", size = 1.00 }, { key = "F1", led = "Keyboard LED 3", size = 1.0 } ... ],
...
// Row 3
[ { key = "tab", led = "Keyboard LED 2", size = 1.50 }, { key = "q", led = "Keyboard LED 3", size = 1.0 } ... ],
// Row 4
[ { key = "caps_lock", led = "Keyboard LED 2", size = 1.75 }, ... ],
...
]
This would allow OpenRGB to generate a more true-to-life visual representation of the keyboard in question, making custom profiles much easier to create or edit. It would also alleviate some quirks of certain keyboards - e.g. my Mid-2021 Razer Blade 17 has "Keyboard LED 1" LEDs defined for all 6 rows, but they're not actually keys, changing their colours affects nothing, and same goes for LEDs 5, 7, 8 and 9 in Row 6 (Space bar), LED 16 in Row 3 (Enter), LEDs 15 and 16 in Row 4 (also Enter). By applying such a configuration on the LED View grid, these unused items can be easily excluded from the flow.
There are a few snags I can already see - while there's a single ID for most models, there are variations in the keyboard layout, things like ANSI vs ISO, QWERTY vs QWERTZ or Dvorak, and so on. By requesting the keyboard layout from the OS (which should be possible on all platforms), and allowing multiple configurations per model (e.g. my laptop would have two distinct layouts, one for ANSI and one for ISO, with the key-specific labels being loaded from the keyboard layout), the actual layout of the keyboard could be drawn on-screen.
I believe that this would be an amazing UX addition to OpenRGB that would promote adoption even by technically less adept people. As a Razer user I think I'm not alone when I say "anything but Synapse". Unfortunately from the two alternatives, Polychromatic does not support Windows, and OpenRGB is far from being user-friendly in general.
For future iterations, completely custom LED zone sizes and shapes could be introduced to support e.g. multi-zone mice, or other peripherals that do not necessarily position their zones on a perfect grid of squares.
In fact I'd probably go even further and permanently enable the LED view, even if the LEDs themselves are not selectable, to at least present a visualisation of the keyboard and the selected animation.