input: update keyboard led state

[cmeissl]

track and update the keyboard led states

depends on Smithay/smithay#1298

fixes #128

[YaLTeR]

After I turn on Num Lock and switch TTY back and forth, the LED remains off until the first keyboard event.

[cmeissl]

After I turn on Num Lock and switch TTY back and forth, the LED remains off until the first keyboard event.

Strange, this works for me just fine and I don't see anything obvious why it shouldn't work. On suspending the libinput session all devices are removed. Upon resume all devices are (re-)added which updates the led state.
I wonder what is different in your setup.

[YaLTeR]

Not sure. I also just noticed that even if the LED is on on the vconsole TTY that I'm switching back and forth with, upon coming back the LED turns off, until some libinput event I guess, moving the mouse or touchpad also updates it back on.

[cmeissl]

I think it is normal that it will turn off, the device has been removed and is re-added. But it should turn back on right away again because the code updates the leds on device re-add. Hard to say why this does not happen. sway and weston will remove the whole keyboard, so it will loose the state.

Which version of libinput do you have installed?
Can you also post your xkb config so I can try with these settings?

[YaLTeR]

libinput-1.25.0-1.fc39.x86_64, happens with the default config too

This is kinda weird, I ran another niri instance on a TTY where I had Num Lock on on the vconsole, and there the LED was turning on on a TTY switch until another libinput event. Then after exiting that niri instance, the LED was off in the vconsole, until I disabled and enabled Num Lock.

[cmeissl]

Okay, I somehow managed to reproduce this, but only when going through gdm after a tty switch.
I added some debug prints and in this case the whole input session seems to be delayed until some input triggers it like moving the mouse.

[cmeissl]

So, I think this is either caused by libinput itself or by the libinput backend in smithay.
I will try to find the root cause, but I don't think this is caused by an issue in this PR or the PR that added support for the led stuff in smithay.

As it seems that both, weston and wlroots, completely remove the keyboard (resetting its state) the num lock is just off there anyway and it might be caused by libinput itself delaying stuff.

[YaLTeR]

I see, interesting. Well it's the only problem I stumbled into so far and it's not really a major one I guess

[cmeissl]

Can reproduce on sway with auto enabled NUMLOCK, led stays off until first physical interaction, so I would say this is a issue in libinput

sway config:

input * {
    xkb_layout "at(nodeadkeys)"
    xkb_numlock enabled
}

[YaLTeR]

Yeah, reproduces in sway for me too.

[YaLTeR]

Thanks