From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: lianzhi chang <changlianzhi@uniontech.com>
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
jirislaby@kernel.org, andriy.shevchenko@linux.intel.com,
282827961@qq.com
Subject: Re: [PATCH v14] tty: Fix the keyboard led light display problem
Date: Tue, 9 Nov 2021 22:41:51 -0800 [thread overview]
Message-ID: <YYtpr/bP0HqBsmbW@google.com> (raw)
In-Reply-To: <20211108055139.7202-1-changlianzhi@uniontech.com>
Hi lianzhi,
On Mon, Nov 08, 2021 at 01:51:39PM +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
We know that Xorg sets kbdmode mode to VC_OFF, but it does not mean that
you can say for sure that it is Xorg instance that controls a VT simply
by observing kb->kbdmode. There may be something else entirely. That is
why you want drivers/tty/vt/keyboard.c to reset LEDs and leave it to
whoever is controlling VT to set them to something else if it is
desired.
> 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@uniontech.com>
> Suggested-by: dmitry.torokhov <dmitry.torokhov@gmail.com>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.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.
> v14:
> Sorry, I forgot to verify the format, it is good now.
>
> drivers/tty/vt/keyboard.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index c7fbbcdcc346..91e1c5d92029 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,20 @@ 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 +1267,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
>
>
>
Thanks.
--
Dmitry
next prev parent reply other threads:[~2021-11-10 6:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 5:51 [PATCH v14] tty: Fix the keyboard led light display problem lianzhi chang
2021-11-08 9:37 ` Andy Shevchenko
2021-11-10 6:41 ` Dmitry Torokhov [this message]
2021-11-10 7:26 ` lianzhi chang
2021-11-25 2:33 ` lianzhi chang
2021-11-25 11:40 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YYtpr/bP0HqBsmbW@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=282827961@qq.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=changlianzhi@uniontech.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.