Bug: cannot control caps lock LED via sysfs while kanata is running

[ahihi]

Requirements

• I've searched platform-specific issues, issues and discussions to see if this has been reported before.
• My issue does not involve multiple simultaneous key presses, OR it does but I've confirmed it is not key rollover or ghosting.

Describe the bug

on Linux, it is normally possible to control the caps lock LED (and others) by writing to the relevant file in /sys/class/leds, e.g. /sys/class/leds/input0::capslock/brightness. but when kanata is running, this no longer works.

Relevant kanata config

(defcfg
  process-unmapped-keys yes
  linux-dev ("/dev/input/by-path/platform-i8042-serio-0-event-kbd")
  linux-continue-if-no-devs-found yes)

(defsrc
 caps
)
(defalias
 hyper (multi lsft lctl lalt lmet)
)
(deflayer base
 @hyper
)

To Reproduce

try

echo 1 | tee '/sys/class/leds/input0::capslock/brightness'

and

echo 0 | tee '/sys/class/leds/input0::capslock/brightness'

(or similar, depending on system) with and without kanata running.

Expected behavior

the LED responds to brightness changes also while kanata is running.

Kanata version

1.9.0

Debug logs

Operating system and I/O mechanism

Linux

Additional context

my config maps caps lock to shift+ctrl+alt+meta, but the problem occurs whether or not the key is actually remapped.

the cause is likely the same as kmonad's similar issue kmonad/kmonad#198 (comment) (EVIOCGRAB). there is also a proposed patch kmonad/kmonad#199.

#2074 is also related.

if i understand correctly the proposed patch in kmonad, the fix would require

1. the Rust evdev patch from Add with_leds and with_sounds to uinput VirtualDeviceBuilder emberian/evdev#167
2. a loop in kanata that listens for LED events and writes them to the real device

i poked around in the code a little and got as far as initializing the VirtualDevice using with_leds from the patched evdev, but not sure how to actually receive the LED events..