I have this USB keyboard: ID 046d:c31d Logitech, Inc. Media Keyboard K200 After a suspend/resume cycle all its LEDs are off even though some of them (I know) must be on, e.g. the NUM lock. Please reset LEDs on resume for USB keyboards, at least this one.
This is reproducible in 5.19.9. Who do I have to CC to address this bug?
Are you trying this in the text console or with X running? Because X takes over LED control (and IIRC does not bother restoring the LEDs).
(In reply to Dmitry Torokhov from comment #2) > Are you trying this in the text console or with X running? Because X takes > over LED control (and IIRC does not bother restoring the LEDs). X is always running here however prior to sleep, NVIDIA drivers switch to the Linux/text console first. And while I was writing it I decided to check whether switching to the text console triggers the bug and ... it does! As soon as I switch to the text console, the Num lock goes out and when I switch back to X, it doesn't turn on. No idea whose bug it is. Looks like the kernel has nothing to do with it. Please advise. I have zero understanding of keyboard LEDs and how the kernel, the text console and X.org all interact.
There are a couple of things to keep in mind: 1. LED state is per-VT and usually the kernel is in control of it and is supposed to restore the state of LEDs when switching between VTs 2. X switches VT it is running on into VC_OFF mode, and essentially takes over handling keyboard (and other input) and controlling LEDs. In this case the kernel has no knowledge of the state of the keyboard/input and so is not aware of what state LEDs should be. There were deficiencies in how we handled VT switch, and I believe they were fixed by: Author: lianzhi chang <changlianzhi@uniontech.com> Date: Wed Dec 15 20:51:25 2021 +0800 tty: Fix the keyboard led light display problem Use the "ctrl+alt+Fn" key combination to switch the system from tty to desktop or switch the system from desktop to tty. After the switch is completed, it is found that the state of the keyboard lock is inconsistent with the state of the keyboard Led light.The reasons are as follows: * The desktop environment (Xorg and other services) is bound to a tty (assuming it is tty1), and the kb->kbdmode attribute value of tty1 will be set to VC_OFF. According to the current code logic, in the desktop environment, the values of ledstate and kb->ledflagstate of tty1 will not be modified anymore, so they are always 0. * When switching between each tty, the final value of ledstate set by the previous tty is compared with the kb->ledflagstate value of the current tty to determine whether to set the state of the keyboard light. The process of switching between desktop and tty is also the process of switching between tty1 and other ttys. There are two situations: - (1) In the desktop environment, tty1 will not set the ledstate, which will cause when switching from the desktop to other ttys, if the desktop lights up the keyboard's led, after the switch is completed, the keyboard's led light will always be on; - (2) When switching from another tty to the desktop, this mechanism will trigger tty1 to set the led state. If other tty lights up the led of the keyboard before switching to the desktop, the led will be forcibly turned off. This situation should be avoided. * The current patch is to solve these problems: When VT is switched, the keyboard led needs to be set once.Ensure that after the switch is completed, the state of the keyboard LED is consistent with the state of the keyboard lock. Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: lianzhi chang <changlianzhi@uniontech.com> Link: https://lore.kernel.org/r/20211215125125.10554-1-changlianzhi@uniontech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> but as you can see from the commit messages there is work that X should be doing as well: it needs to detect when VT is switched to the one it is controlling and restore LED state according to its own internal state. It needs to do the same on resume.
It feels like it's a bug in the Xorg server/Fedora 36. Marking invalid.