From: "dmitry.torokhov" <dmitry.torokhov@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: 常廉志 <changlianzhi@uniontech.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
jirislaby <jirislaby@kernel.org>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
282827961 <282827961@qq.com>
Subject: Re: [PATCH v9] tty: Fix the keyboard led light display problem
Date: Mon, 1 Nov 2021 09:35:32 -0700 [thread overview]
Message-ID: <YYAXVP4v2bCpGA8s@google.com> (raw)
In-Reply-To: <YX/iGfXdc8UKUFCx@kroah.com>
On Mon, Nov 01, 2021 at 01:48:25PM +0100, Greg KH wrote:
> On Mon, Nov 01, 2021 at 08:35:47PM +0800, 常廉志 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.
> > >
> > > 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.
> > >
> > > v9: Change description information: xorg-->Xorg
> > > ……
> >
> > Hi, friends, I would like to ask whether this version of patch is possible, if not,
> > I will try my best to find a way to complete the next version!
>
> It's the merge window right now, we can't do anything with this until
> after 5.16-rc1 is out. So give us until then at the least please, then
> I will review it again.
As I mentioned, the state of physical LED on a keyboard does not
necessarily reflect state of logical LED state in tty/vt. One can assign
LED on their keyboard to be an indicator of being connected to mains by
assigning "AC-trigger" to it. So the way this patch tries to fix the
issue (by reading internal state of an individual input device) is
wrong.
We keep separate led and lock states for each VT instance, and they
should be applied when switching to/from a VT. Are you saying that in
certain scenarios this switch is not happening? Can see if that can be
fixed?
Thanks.
--
Dmitry
next prev parent reply other threads:[~2021-11-01 16:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 12:35 Re:[PATCH v9] tty: Fix the keyboard led light display problem 常廉志
2021-11-01 12:48 ` [PATCH " Greg KH
2021-11-01 16:35 ` dmitry.torokhov [this message]
2021-11-02 3:16 ` 常廉志
2021-11-02 4:02 ` dmitry.torokhov
2021-11-02 7:09 ` 常廉志
2021-11-02 23:51 ` dmitry.torokhov
-- strict thread matches above, loose matches on Subject: below --
2021-10-27 5:35 lianzhi chang
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=YYAXVP4v2bCpGA8s@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox