[BUG] Lock key LEDs turn off when keyszer bails, but lock key state doesn't change

[RedBearAK]

Very minor issue to look at in the future. When quitting keyszer with the bailout key, I've noticed that the physical lock key LEDs (if present) on the keyboard will turn off (if they are on), but the state of the lock key(s) as far as the OS is concerned remains active. For instance, letters will produce ALL CAPS and numpad will produce numbers, and a GNOME shell extension that displays the lock keys state independently of any physical keyboard LEDs will continue to show the lock keys as active.

Tapping one of the two lock keys will re-enable the other lock key LED on the keyboard, if both lock keys were in the enabled state when quitting keyszer. So the OS (or WM, or DE) appears to refresh all lock key LED states on all attached keyboard devices when any individual lock key is pressed.

I have a feeling I might have seen this in the past with xkeysnail, so this may be an inherited behavior.

[joshgoebel]

Can you confirm behavior with REAL physical keyboards? I mean stopping keyser is essentially unplugging a keyboard... I wonder if perhaps this is more of a kernel bug/issue than our problem (even if we might need to solve it)... We don't do anything in particular to change the LED states on close.

[RedBearAK]

Can you confirm behavior with REAL physical keyboards? I mean stopping keyser is essentially unplugging a keyboard

Don't know what the first part of this is referring to. The LEDs are already on a physical Apple USB external keyboard connected to my laptop.

[joshgoebel]

I was asking if you can screw up the state of leds by unplugging and replugging regular old keyboArds.

[RedBearAK]

I was asking if you can screw up the state of leds by unplugging and replugging regular old keyboArds.

Ahhhh... I don't believe I've ever witnessed anything like that. Let's see.

No, plugging in the USB keyboard always seems to initialize the lights to the actual state of the lock keys, and disconnecting and reconnecting always works the same way. With and without keyszer running, and either lock key enabled or both.

But quitting keyszer with the USB keyboard connected will always turn any lit LEDs on the physical keyboard off. 100% repeatable.

I don't think I have a laptop around with physical LEDs for the internal keyboard (mostly MacBooks in the house), but I suspect that all "grabbed" keyboard devices will have their LEDs turned off in the same way upon exiting xkeysnail or keyszer. Maybe something is really treating the physical keyboard as "unplugged" until receiving another key press event from it. No idea.

[joshgoebel]

I wonder if we could make a tiny test case of just creating a UInput device and then closing it... I wonder if that causes the issue as well. I think first we need to determine if this is a keyszer or uinput bug before we could assign a priority.

[RedBearAK]

I wonder if we could make a tiny test case of just creating a UInput device and then closing it... I wonder if that causes the issue as well. I think first we need to determine if this is a keyszer or uinput bug before we could assign a priority.

I consider the LED problem a very low priority for now, since it's basically cosmetic and self-fixing to a certain extent. Most users have probably never noticed it, nor ever will. But if you want me to test something at some point to help pin down the cause, let me know.

[joshgoebel]

Related: gvalkov/python-evdev#107 (comment)

[RedBearAK]

Probably doesn't make much sense to keep this open then, if there is nothing that even evdev can do to fix it.

[RedBearAK]

Another thing I noticed is that pressing one of caps/numlock restores the led state of both leds.

The initial post mentions the behavior I saw myself. The OS/kernel or X11 will reset both LED states to what they should be as soon as you press either lock key.

I'd mark this as "won't fix" and be done with it.

[joshgoebel]

I'll leave it open a bit longer - if there is some cleanup we could do - might be a fun project for someone. If we're about to become part of Kinto then we're about to get a bit popular and maybe that'll bring a few volunteers interested in some of this kind of work.