feat(underglow): support command for displaying board statuses

[nVitius]

The MoErgo ZMK fork has some cool functionality for displaying board status indicators on the Glove80 using underglow and an RGB command. Until recently, this had been dependent on two outstanding PRs: #999 and #1243. Both of which have been merged in at this point.

This PR ports the code from MoErgo's fork (reference).

I've refactored a bit of the code to be more legible as well as added comments here and there.
The functionality between my version and MoErgo's is almost exactly the same with a couple exceptions:

• The properties for the underglow-indicators DT node are all optional now. This means you can pick and choose which indicators you would like to use
• A couple of the properties are renamed to be a bit more clear (in my opinion)

Here is an example of how this is used in a dts:

And here is a short video of what that looks like on my Cyboard Imprint:
https://github.com/zmkfirmware/zmk/assets/3804041/8a06fe6b-9e25-45ae-89d1-7b047fb541fc

I've never written C code before, so if you have any improvements or suggestions, I am happy to hear them.

[caksoylar]

I think this would at least need some way to extend to multiple splits. The way it is hardcoded with lhs and rhs doesn't seem flexible. Maybe make it N child nodes for splits with N parts.

You could also consider making this a module so that people can use and test it without having to switch ZMK branches.

[nVitius]

@caksoylar Thanks for your input!

I've updated the PR to support a dynamic number of peripherals. The new configuration looks like this:

I'll look into making this a module, but I think it will require changes to rgb_underglow.c regardless, as we use the pixels global in there to actually display the indicators.

[ReFil]

@nVitius you can replace source files inside a module, see this from badjeff https://github.com/badjeff/zmk-split-peripheral-bonding-tweak/blob/0671c2148db4f695b6771bc834bf52b0946799de/CMakeLists.txt#L21-L25

[nVitius]

@ReFil Thanks for the link!

Is that really best practice? Seems really wrong to replace parts of the codebase from a module like that.