linux-kernel - [PATCH v13] tty: Fix the keyboard led light display problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211108054510.4680-1-changlianzhi@uniontech.com>
Date:   Mon,  8 Nov 2021 13:45:10 +0800
From:   lianzhi chang <changlianzhi@...ontech.com>
To:     linux-kernel@...r.kernel.org
Cc:     dmitry.torokhov@...il.com, gregkh@...uxfoundation.org,
        jirislaby@...nel.org, andriy.shevchenko@...ux.intel.com,
        282827961@...com, lianzhi chang <changlianzhi@...ontech.com>
Subject: [PATCH v13] tty: Fix the keyboard led light display problem

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.
In order to ensure that the keyboard LED lights are displayed
normally during the VT switching process, when the VT is
switched, the current VT LED configuration is forced to be issued.

Signed-off-by: lianzhi chang <changlianzhi@...ontech.com>
Suggested-by: dmitry.torokhov <dmitry.torokhov@...il.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
---
 v13:
 The kbd_bh function no longer handles the "kb->kbdmode == VC_OFF"
 scene, but puts this process in vt_set_leds_compute_shiftstate
 together. Because the current circumvention is that other ttys
 switch to the Xorg-bound tty scene, so this Better.
 
 drivers/tty/vt/keyboard.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index c7fbbcdcc346..ede9206d6c99 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -153,6 +153,7 @@ static int shift_state = 0;
 
 static unsigned int ledstate = -1U;			/* undefined */
 static unsigned char ledioctl;
+static bool vt_switch;
 
 /*
  * Notifier list for console keyboard events
@@ -412,9 +413,21 @@ static void do_compute_shiftstate(void)
 /* We still have to export this method to vt.c */
 void vt_set_leds_compute_shiftstate(void)
 {
+	struct kbd_struct *kb;
 	unsigned long flags;
 
-	set_leds();
+	/* Xorg will bind a tty, the kb->kbdmode of this tty will be set to 
+	 * VC_OFF, and this tty will no longer set the keyboard light. If 
+	 * there is no such restriction, when switching from other tty to 
+	 * Xorg-bound tty, the tty will set the keyboard light, which is 
+	 * unreasonable
+	 */
+	kb = kbd_table + fg_console;
+	if (kb->kbdmode != VC_OFF)
+	{
+		vt_switch = true;
+		set_leds();
+	}
 
 	spin_lock_irqsave(&kbd_event_lock, flags);
 	do_compute_shiftstate();
@@ -1255,6 +1268,11 @@ static void kbd_bh(struct tasklet_struct *unused)
 	leds |= (unsigned int)kbd->lockstate << 8;
 	spin_unlock_irqrestore(&led_lock, flags);
 
+	if (vt_switch) {
+		ledstate = ~leds;
+		vt_switch = false;
+	}
+
 	if (leds != ledstate) {
 		kbd_propagate_led_state(ledstate, leds);
 		ledstate = leds;
-- 
2.20.1