ZMK indicator LED support

[khoek]

I'm interested in contributing first class indicator LED support (e.g. CAPS/SCROLL/NUMLOCK being displayed as RGB LEDs; the Adv360 fork currently implements this via some ad hoc extensions to the rgb underglow code). Is work on this ongoing/have there been previous attempts?

Contemplating the natural way indicator LEDs are extensible (e.g. to display onboard battery level) I thought for a moment conceptually it could be useful to view e.g. 3 indicator LEDs as the most rudimentary possible display. But from what I can see there is a relatively sophisticated widget system which doesn't seem like it would play well with this perspective, so I guess that's a non-starter.

But at any rate, getting support for e.g. what the Advantage custom fork is trying to do (display HID indicator state, battery, and layer) would be my initial intention. I think this lends itself well to a device tree-style configuration where one is able to bind specific indicator LEDs to specific functions (a particular HID state like capslock, or the current layer, or bluetooth state). A custom command (e.g. &ind IND_BATTERY_CMD) could by keypress override the indicators to show battery level based on color.

How much have people thought about this in the past/what are people thinking?

[ReFil]

Hi, I think there might be some upstream PRs with similar sort of functionality open, I also think the MoErgo glove80 uses some devicetree configurability in its RGB implementation. We have been wanting to transition to a more refined indicators framework at some point, driven by events rather than a timer.

To that extent we have opened a pr for the left right auxiliary communication channel we use to transmit keymap state and other info over to the right hand side zmkfirmware/zmk#2036

[khoek]

Thanks for the info. That PR looks very important for anything split; I'll take a look!

[khoek]

Just a little more theorycrafting; I see in the Glove80 .dts files different LEDs are used for e.g. different BT profiles and this fits nicely with devicetree. In the case where we want a single LED to indicate different states via color, has configuring anything like that (perhaps just by a variable length list) been done before using the devicetree language? (I'm not familiar enough to know what is idiomatic for devicetree, but I'd be grateful for any sort of source/example/analogous thing you'd be able to point me to.)

[ReFil]

Lots of things in devicetree are variable length lists, e.g. GPIO lists for rows and columns. The important thing is that devicetree stuff gets compiled down to glorifiec C macros. so it has to be static. The zephyr documentation on devicetree can be found here: https://docs.zephyrproject.org/latest/build/dts/api-usage.html

As for other projects usign devicetree, you could perhaps look at https://github.com/ReFil/zmk/tree/rotrlayer and it's corresponmding documentation here: https://docs.google.com/document/d/1nOHC0R_G6HR0cCJJgpj22CC5Q_K_o-7oYNo1CTE4pvk/edit?usp=sharing on doing layer indications inside the keymap file as it's also devicetree. although given there is upcoming work on vial-like keymap editing i would not recreate this functionality using the keymap file, it would be better to do it in the .dts file