Caps Lock LED indicator for Defy/Raise

[Vitnir]

Hi Dygma team,

I would like to contribute a Caps Lock LED indicator feature.

Problem

On keyboards without a dedicated Caps Lock indicator, it is easy to accidentally type in uppercase, only notice after writing, disable Caps Lock, and retype. I would like the Caps Lock key LED to change color while the host reports Caps Lock as active.

Proposed behavior

• Firmware detects the host Caps Lock LED state.
• If Caps Lock is active, the physical key currently mapped to Caps Lock is highlighted with a configurable color.
• If Caps Lock is inactive, normal LED behavior is restored.
• Bazecor exposes this as an optional LED setting:
  • enabled/disabled
  • indicator color

Compatibility approach

• Bazecor should only show the setting when firmware exposes the required Focus commands via help.
• Older firmware should continue to work unchanged.
• The UI should remain configuration-only; the actual behavior belongs in firmware.

Implementation sketch

Firmware Focus commands:

• led.capsLockIndicator.enabled
• led.capsLockIndicator.color

Firmware responsibilities:

• Store the setting in EEPROM/config.
• Read the host Caps Lock LED state.
• Locate the physical key currently mapped to Key_CapsLock on the active keymap/layer.
• Apply a temporary LED overlay for that key while Caps Lock is active.
• Restore normal LED behavior when Caps Lock is inactive.

Bazecor responsibilities:

• Discover support through help.
• Read/write the setting in Preferences > LEDs.
• Hide the setting for firmware that does not expose the commands.

Kaleidoscope findings

After looking further into the upstream firmware stack, keyboardio/Kaleidoscope looks highly relevant here:

• https://github.com/keyboardio/Kaleidoscope
• https://kaleidoscope.keyboard.io/keyboards/

The Kaleidoscope documentation describes it as firmware for Arduino-powered keyboards and lists Dygma Raise as a Kaleidoscope-powered keyboard. There are also older Keyboardio community discussions showing the same general pattern for Caps Lock LED behavior:

• https://community.keyboard.io/t/current-equivalent-of-useloophook-for-highlighting-single-capslock-led/1667
• https://community.keyboard.io/t/kaleidoscope-capslock-turns-letter-keys-red-when-caps-lock-is-on/993

The important upstream pattern appears to be reading the host LED state with something equivalent to:

kaleidoscope::hid::getKeyboardLEDs() & LED_CAPS_LOCK

and then setting or refreshing the relevant LED.

However, the Defy Wireless firmware layout appears to have an additional Dygma-specific adapter layer. In NeuronWirelessLibs/.gitmodules, the firmware references:

[submodule "kaleidoscope_adapter"]
  path = kaleidoscope_adapter
  url = git@github.com:Dygmalab/kaleidoscope_adapter.git
  branch = main

So my current understanding is:

• keyboardio/Kaleidoscope likely provides the upstream concept/API pattern.
• Dygmalab/kaleidoscope_adapter likely provides the Defy-specific bridge to keyboard_api.h, kbdapi, kbdif, keymap access, and layer/key events.
• The Defy Wireless architecture also involves Neuron + side keyscanners + remote LED handling, so the final integration may need to happen through Dygma's adapter/LED pipeline rather than as a plain standalone Kaleidoscope plugin.

Draft PRs

I opened draft PRs as an implementation example:

• Bazecor UI/config: Add Caps Lock indicator LED setting #1125
• Defy Neuron config wiring: Wire Caps Lock indicator config storage NeuronWireless_defy#23
• Shared firmware config item: Add Caps Lock indicator config item NeuronWirelessLibs#35
• LEDManager Focus commands: Add Caps Lock indicator LED config commands NeuronLedLibrary#10

Current status of the drafts:

• Bazecor UI is gated by Focus help, so older firmware should not expose the setting.
• Firmware config storage and Focus commands are drafted.
• The live overlay behavior is intentionally not complete yet.

Open questions

1. Is Dygmalab/kaleidoscope_adapter intended to be accessible to external contributors, or is there another preferred public API/path for this integration?
2. For Defy Wireless specifically, should the live Caps Lock LED behavior be implemented in NeuronLedLibrary, in the Kaleidoscope adapter layer, or closer to the side keyscanner LED pipeline?
3. Is the preferred host-state source still the Kaleidoscope/HID LED state pattern, or does the Defy Wireless stack already expose a Dygma-specific host LED-state event?
4. Should the firmware highlight only keys currently mapped to Key_CapsLock, or should Bazecor allow selecting an arbitrary indicator key?

The remaining firmware piece is: detect host Caps Lock state, locate the active Caps Lock key, and temporarily override its LED color without disrupting the regular LED mode.