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-prev] [day] [month] [year] [list]
Message-ID: <YaC9so4FippjDCKK@kroah.com>
Date:   Fri, 26 Nov 2021 11:57:54 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     lianzhi chang <changlianzhi@...ontech.com>
Cc:     linux-kernel@...r.kernel.org, dmitry.torokhov@...il.com,
        jirislaby@...nel.org, andriy.shevchenko@...ux.intel.com,
        282827961@...com
Subject: Re: [PATCH v16] tty: Fix the keyboard led light display problem

On Fri, Nov 26, 2021 at 06:48:32PM +0800, lianzhi chang wrote:
> When the desktop and tty switch mutually, the led state of the
> keyboard may be inconsistent with the state of the keyboard lock.
> This is because the desktop environment (Xorg, etc.) is bound to
> a tty, and the kb->kbdmode attribute of this tty is set to VC_OFF.
> This leads to the fact that in the desktop environment, the bound
> tty will not set the keyboard light state, so in the current tty
> scene, the values of ledstate and kb->ledflagstate are always 0.
> This leads to two situations: (1) When switching from the desktop
> to another tty, the code inside VT still compares ledstate with
> the kb->ledflagstate of the next tty. If they are equal, then
> after the switch is completed, The keyboard light will maintain
> the state of the previous desktop settings, and the state of the
> keyboard lock may be inconsistent; (2) When switching from another
> tty to the desktop, according to the code logic, it may still
> trigger the desktop bound tty to set the keyboard light state.
> After the switch is completed, the keyboard light is forcibly
> turned off. I think in this case, the tty should not set the
> keyboard light, and give control to Xorg etc. to handle it.
> The current modification judges the value of kb->kbdmode.
> In some modes, when switching VT, the current tty keyboard
> light status is forcibly issued. And when switching to the
> desktop, the tty no longer sets the keyboard light.

That is a "wall of text" that is impossible to read.

Please consider formatting it so that it is understandable.  Would you
want to read that and attempt to understand what is going on?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ