Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   lianzhi chang <changlianzhi@uniontech.com>
To:     linux-kernel@vger.kernel.org
Cc:     dmitry.torokhov@gmail.com, gregkh@linuxfoundation.org,
        jirislaby@kernel.org, andriy.shevchenko@linux.intel.com,
        282827961@qq.com, lianzhi chang <changlianzhi@uniontech.com>
Subject: [PATCH v8] tty: Fix the keyboard led light display problem
Date:   Wed, 27 Oct 2021 12:15:43 +0800
Message-Id: <20211027041543.20579-1-changlianzhi@uniontech.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Feedback-ID: bizesmtp:uniontech.com:qybgforeign:qybgforeign5
Precedence: bulk

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>
---
 v7-->v8:
 Optimize the implementation of kbd_update_ledstate function
 
 Why not adopt the opinions of Greg KH and Andy Shevchenko:
 (1) In the structure struct input_dev, the definition of led is
 like this: unsigned long led[BITS_TO_LONGS(LED_CNT)]; If you
 define it like this: unsigned long newstate = *dev->led; I
 always feel that there is still big end and Little endian problem.
 (2) The test_bit function is used to avoid the problem of large
 and small ends, and the current algorithm (v8) also exists 
 elsewhere in the kernel: the atkbd_set_leds function (drivers/
 input/keyboard/atkbd.c).
 (3) In the current keyboard.c code, the code is already very good,
 and it is already relatively independent. If you modify the type 
 of ledstate to u64 or modify the macro definitions such as
 VC_NUMLOCK, it feels that it is not very meaningful, and this It 
 will also cause other related modifications. Of course, this is
 only my current opinion. If everyone still feels that it is 
 necessary to modify, I will do it this way. Of course, this 
 process may be a bit longer, and I think it is necessary to
 conduct more tests.
 
 drivers/tty/vt/keyboard.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index c7fbbcdcc346..f564fcf61304 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1130,6 +1130,13 @@ static void kbd_init_leds(void)
 
 #endif
 
+static void kbd_update_ledstate(struct input_dev *dev)
+{
+	ledstate = (test_bit(LED_SCROLLL, dev->led) ? BIT(VC_SCROLLOCK) : 0)
+		 | (test_bit(LED_NUML,    dev->led) ? BIT(VC_NUMLOCK) : 0)
+		 | (test_bit(LED_CAPSL,   dev->led) ? BIT(VC_CAPSLOCK) : 0);
+}
+
 /*
  * 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 +1254,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 +1536,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