[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YYjvlb0taamSTElN@smile.fi.intel.com>
Date: Mon, 8 Nov 2021 11:36:21 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: lianzhi chang <changlianzhi@...ontech.com>
Cc: linux-kernel@...r.kernel.org, dmitry.torokhov@...il.com,
gregkh@...uxfoundation.org, jirislaby@...nel.org, 282827961@...com
Subject: Re: [PATCH v13] tty: Fix the keyboard led light display problem
On Mon, Nov 08, 2021 at 01:45:10PM +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.
> 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.
...
> Suggested-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Shouldn't be here. I haven't suggested the current implementation.
What I had done is proposed changes to one of the previous versions
which was wrong from design perspective and got rejected.
...
> + /* 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
> + */
trailing whitespaces. Had you run checkpatch?
Even Git warns about them when you do `git commit ...`
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists