Bug 216274

Summary:	Keyboard LEDs must be reset on resume
Product:	Drivers	Reporter:	Artem S. Tashkinov (aros)
Component:	Input Devices	Assignee:	drivers_input-devices
Status:	RESOLVED INVALID
Severity:	normal	CC:	dmitry.torokhov
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	5.18.10	Subsystem:
Regression:	No	Bisected commit-id:

Description Artem S. Tashkinov 2022-07-23 11:02:36 UTC

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.

Comment 1 Artem S. Tashkinov 2022-09-19 12:06:50 UTC

This is reproducible in 5.19.9.

Who do I have to CC to address this bug?

Comment 2 Dmitry Torokhov 2022-10-28 00:09:00 UTC

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).

Comment 3 Artem S. Tashkinov 2022-10-28 00:14:24 UTC

(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.

Comment 4 Dmitry Torokhov 2022-10-28 05:01:40 UTC

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.

Comment 5 Artem S. Tashkinov 2022-11-09 11:23:23 UTC

It feels like it's a bug in the Xorg server/Fedora 36.

Marking invalid.