[PATCH v6] tty: Fix the keyboard led light display problem

[PATCH v6] tty: Fix the keyboard led light display problem

[lianzhi chang]

Switching from the desktop environment to the tty environment,
the state of the keyboard led lights and the state of the keyboard
lock are inconsistent. This is because the attribute kb->kbdmode
of the tty bound in the desktop environment (xorg) is set to
VC_OFF, which causes the ledstate and kb->ledflagstate
values of the bound tty to always be 0, which causes the switch
from the desktop When to the tty environment, the LED light
status is inconsistent with the keyboard lock status.

Signed-off-by: lianzhi chang <changlianzhi@uniontech.com>
---
 v2-->v3:
 (1) Abandon the previous modification plan.
 (2) Added the kbd_update_ledstate function, this function gets the
 latest state of the led from the input device, and then synchronizes
 it to the ledstate. The kbd_event function calls it.
 (3) When the tty's kbdmode==VC_OFF, the tty does not set the keyboard light (modify the kbd_bh function).
 v3-->v4:
 Correct the subject
 v5:
 Some code adjustments
 
 Why didn't you follow Dmitry's advice:
 According to Dmitry's suggestion, modifying the code should not involve
 changes to the input core, and only needs to be done in keyboard.c. According
 to my previous patch logic, it is impossible not to involve changes to the
 input core. So it was changed to the current patch.
 
 test_bit(EV_LED, dev->evbit) is used to detect whether the input device
 supports EV_LED, I think it should exist. "If (ledstate == -1U)" is
 because the initialized value of ledstate is -1U, I think it should exist.
 V6:
 (1)I deleted "if (ledstate == -1U)", and after careful consideration, my
 thoughts are superfluous.
 (2)Format adjustment and a wrong parameter modification
 
 drivers/tty/vt/keyboard.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index c7fbbcdcc346..9194ad92f062 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1130,6 +1130,20 @@ static void kbd_init_leds(void)
 
 #endif
 
+static void kbd_update_ledstate(struct input_dev *dev)
+{
+	unsigned long leds;
+
+	leds = (unsigned long)ledstate;
+
+	if (!!test_bit(LED_NUML, dev->led) != !!test_bit(VC_NUMLOCK, &leds))
+		ledstate ^= BIT(VC_NUMLOCK);
+	if (!!test_bit(LED_CAPSL, dev->led) != !!test_bit(VC_CAPSLOCK, &leds))
+		ledstate ^= BIT(VC_CAPSLOCK);
+	if (!!test_bit(LED_SCROLLL, dev->led) != !!test_bit(VC_SCROLLOCK, &leds))
+		ledstate ^= BIT(VC_SCROLLOCK);
+}
+
 /*
  * The leds display either (i) the status of NumLock, CapsLock, ScrollLock,
  * or (ii) whatever pattern of lights people want to show using KDSETLED,
@@ -1247,9 +1261,14 @@ void vt_kbd_con_stop(unsigned int console)
  */
 static void kbd_bh(struct tasklet_struct *unused)
 {
+	struct kbd_struct *kb;
 	unsigned int leds;
 	unsigned long flags;
 
+	kb = kbd_table + fg_console;
+	if (kb->kbdmode == VC_OFF)
+		return;
+
 	spin_lock_irqsave(&led_lock, flags);
 	leds = getleds();
 	leds |= (unsigned int)kbd->lockstate << 8;
@@ -1524,6 +1543,9 @@ static void kbd_event(struct input_handle *handle, unsigned int event_type,
 	/* We are called with interrupts disabled, just take the lock */
 	spin_lock(&kbd_event_lock);
 
+	if (test_bit(EV_LED, handle->dev->evbit))
+		kbd_update_ledstate(handle->dev);
+
 	if (event_type == EV_MSC && event_code == MSC_RAW &&
 			kbd_is_hw_raw(handle->dev))
 		kbd_rawcode(value);
-- 
2.20.1

Re: [PATCH v6] tty: Fix the keyboard led light display problem

[Andy Shevchenko]

On Thu, Oct 21, 2021 at 10:05:11AM +0800, lianzhi chang wrote:
> Switching from the desktop environment to the tty environment,
> the state of the keyboard led lights and the state of the keyboard
> lock are inconsistent. This is because the attribute kb->kbdmode
> of the tty bound in the desktop environment (xorg) is set to
> VC_OFF, which causes the ledstate and kb->ledflagstate
> values of the bound tty to always be 0, which causes the switch
> from the desktop When to the tty environment, the LED light
> status is inconsistent with the keyboard lock status.

...

> +	unsigned long leds;
> +
> +	leds = (unsigned long)ledstate;

Can be one line.

But most important question you are ignoring to answer / address is why do you
use casting?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6] tty: Fix the keyboard led light display problem

[andriy.shevchenko]

On Mon, Oct 25, 2021 at 01:29:18AM +0800, changlianzhi@uniontech.com wrote:
> >>On Thu, Oct 21, 2021 at 10:05:11AM +0800, lianzhi chang wrote:
> >> Switching from the desktop environment to the tty environment,
> >> the state of the keyboard led lights and the state of the keyboard
> >> lock are inconsistent. This is because the attribute kb->kbdmode
> >> of the tty bound in the desktop environment (xorg) is set to
> >> VC_OFF, which causes the ledstate and kb->ledflagstate
> >> values of the bound tty to always be 0, which causes the switch
> >> from the desktop When to the tty environment, the LED light
> >> status is inconsistent with the keyboard lock status.
> 
> >...
> 
> >> +	unsigned long leds;
> >> +
> >> +	leds = (unsigned long)ledstate;
> 
> >Can be one line.
> 
> >But most important question you are ignoring to answer / address is why do you
> >use casting?

> >>But most important question you are ignoring to answer / address is why do you
> >>use casting?
> Casting is used here because:
> The second parameter of test_bit is "volatile unsigned long *addr" (see constant_test_bit() in /arch/x86/include/asm/bitops.h), but ledstate is an "unsigned int" type. If casting is not used,
> compile Will report an error.

Wait, you are casting pointer to an integer?!
This is completely wrong in this case!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6] tty: Fix the keyboard led light display problem

[andriy.shevchenko]

On Mon, Oct 25, 2021 at 12:24:45PM +0800, changlianzhi@uniontech.com wrote:
> On Mon, Oct 25, 2021 at 01:29:18AM +0800, changlianzhi@uniontech.com wrote:
> > > >>On Thu, Oct 21, 2021 at 10:05:11AM +0800, lianzhi chang wrote:

...

> > > >> +	unsigned long leds;
> > > >> +
> > > >> +	leds = (unsigned long)ledstate;
> > >
> > > >Can be one line.
> > >
> > > >But most important question you are ignoring to answer / address is why do you
> > > >use casting?
> 
> > > >>But most important question you are ignoring to answer / address is why do you
> > > >>use casting?
> > > Casting is used here because:
> > > The second parameter of test_bit is "volatile unsigned long *addr" (see constant_test_bit() in /arch/x86/include/asm/bitops.h), but ledstate is an "unsigned int" type. If casting is not used,
> > > compile Will report an error.
> 
> > Wait, you are casting pointer to an integer?!
> > This is completely wrong in this case!
> 
> Hello, I did not do that. For the complete code, please check the
> "patch v6" email I sent earlier. My code is like this:

> +static void kbd_update_ledstate(struct input_dev *dev)
> +{
> +	unsigned long leds;
> +
> +	leds = (unsigned long)ledstate;
> +
> +	if (!!test_bit(LED_NUML, dev->led) != !!test_bit(VC_NUMLOCK, &leds))
> +	ledstate ^= BIT(VC_NUMLOCK);
> +	if (!!test_bit(LED_CAPSL, dev->led) != !!test_bit(VC_CAPSLOCK, &leds))
> +	ledstate ^= BIT(VC_CAPSLOCK);
> +	if (!!test_bit(LED_SCROLLL, dev->led) != !!test_bit(VC_SCROLLOCK, &leds))
> +	ledstate ^= BIT(VC_SCROLLOCK);
> +}

> I mean, the second parameter of test_bit is "volatile unsigned long *addr",
> which is a pointer. And ledstate is an unsigned int type, so I defined an
> unsigned long type leds, assign the ledstate to the leds after forced
> conversion, and then when calling the test_bit function, get the address
> of the leds as a parameter.

This all is fine, but why casting is needed? I didn't still get.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6] tty: Fix the keyboard led light display problem

[Dmitry Torokhov]

Hi,

On Thu, Oct 21, 2021 at 10:05:11AM +0800, lianzhi chang wrote:
> @@ -1524,6 +1543,9 @@ static void kbd_event(struct input_handle *handle, unsigned int event_type,
>  	/* We are called with interrupts disabled, just take the lock */
>  	spin_lock(&kbd_event_lock);
>  
> +	if (test_bit(EV_LED, handle->dev->evbit))
> +		kbd_update_ledstate(handle->dev);
> +

Why do we need to update led state on each and every event instead of
trapping individual EV_LED/LED_x events?

But thinking about it some more, I believe doing this here is wrong.
LEDs are routed in this way:

   device <-> input core <-> input leds <-> leds core <-> VT

with the last step assuming that we are in default configuration and we
indeed assign one of the following triggers to appropriate LED on given
device:

kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock
kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock
kbd-ctrlllock kbd-ctrlrlock

I.e. the state of LED of individual input device is not necessarily
attached to LED flag state in a given VT.

Re-reading the patch description, are we saying that we are maintaining
kbd->[s]lockstate, but losing kbd->ledflagstate when we are doing
transitions to and from VC_OFF state? We need to keep in mind that we
are trying to keep states separate on separate consoles.

Thanks.

-- 
Dmitry