Keybard<->Svalboard communication and customizable layer colors.

[captdeaf]

Adds communication between Keybard and Sval that works alongside Vial. Vial will still work, but won't be able to access any of the Sval-specific features.

Sval requests begin with 0xEE (SVAL_VIA_PREFIX) and are followed by a 1-byte command.

sval_id_get_protocol_version - Requests a Sval protocol version. Keybard will use this to determine if the connected keyboard has additional features. Response is ['s','v','a','l'] followed by version as a little-endian 4-byte int. [1, 0, 0, 0] at present.

sval_id_get_firmware_version - Requests the QMK_VERSION string from the Sval. e.g: 'v24.10.24-4-g2fcc7c-dirty'

sval_id_get_layer_hsv Fetches a layer's HSV. Response is [H, S, V]

sval_id_set_layer_hsv, <layer>, <hue>, <sat>, <val>] - Set a layer's HSV. No response expected.

[ilc]

I wonder if we are going too far to defeat a bug that we already don't care about? (Split reconnect having out of sync leds.)

Plenty of questions of "why" things are being done, like the ping across the split, the fact this is all HSV is odd? (The LEDs are GBR I think?) But in the end, we can convert from one to the other.

May be worth recording some of why in the code.

[captdeaf]

Split reconnect having out of sync leds.

Totally fine ditching the IPC.

all HSV

HSV and RGB take separate code paths. RGB does not work with split keyboards. HSV does. This post is a bit outdated, but still applicable:

https://www.reddit.com/r/olkb/comments/pllnt4/qmk_only_half_of_my_split_kb_lights_up/?rdt=47247

LEDs are GBR

I don't know if this is a QMK bug or hardware artifact, but when I added an RGB->HSV converter (on Keybard side), only a limited number of colors actually worked. With HSV, all Hs work, but only S=1.0/255 had consistently working colors. I'll dig into this more when I'm back at my sval.

[ilc]

The QMK code sounds worse in this area than normal.... I want to take a look at wtf they did.