linux-kernel - Re: [PATCH v4 1/2] Input: Add a Kconfig to emulate KEY

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7tnn7sa654c3irqxprnqgbxawl6pnvuuonps3t5qkhso3h6fp6@fc3ph7fkukgm>
Date: Sun, 27 Apr 2025 22:30:24 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Mario Limonciello <superm1@...nel.org>
Cc: Pavel Machek <pavel@....cz>, 
	Shyam Sundar S K <Shyam-sundar.S-k@....com>, Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	Hans de Goede <hdegoede@...hat.com>, 
	"open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)..." <linux-input@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, 
	"open list:AMD PMF DRIVER" <platform-driver-x86@...r.kernel.org>, Mario Limonciello <mario.limonciello@....com>, 
	Armin Wolf <W_Armin@....de>
Subject: Re: [PATCH v4 1/2] Input: Add a Kconfig to emulate KEY_SCREENLOCK
 with META + L

Apologies for extended absence...

On Sun, Apr 27, 2025 at 07:15:31AM -0500, Mario Limonciello wrote:
> 
> 
> On 4/27/25 01:10, Pavel Machek wrote:
> > Hi!
> > 
> > > > > > > In the PC industry KEY_SCREENLOCK isn't used as frequently as it used
> > > > > > > to be. Modern versions of Windows [1], GNOME and KDE support "META" + "L"
> > > > > > > to lock the screen. Modern hardware [2] also sends this sequence of
> > > > > > > events for keys with a silkscreen for screen lock.
> > > > > > > 
> > > > > > > Introduced a new Kconfig option that will change KEY_SCREENLOCK when
> > > > > > > emitted by driver to META + L.
> > > > > > 
> > > > > > Fix gnome and kde, do not break kernel...
> > > > > 
> > > > > I'm sorry; fix them to do what exactly?  Switch to KEY_SCREENLOCK?
> > > > > 
> > > > > That's going to break modern hardware lockscreen keys.  They've all
> > > > > obviously moved to META+L because that's what hardware today uses.

Vendors do all kind of weird things. They want to ship their
peripherals here and now and they do not care of shortcuts will change a
few years down the road.

FWIW there are plenty of external keyboards that use KEY_SCREENLOCK and
do not emit any shortcurts. Anything that is "Woks with Chromebooks"
will use KEY_SCREENLOCK.


> > > > 
> > > > Gnome / KDE should accept either META+L _or_ KEY_SCREENLOCK to do the
> > > > screen locking, no?

KDE by default recognizes Meta+L combination (which used to be
Alt+Ctrl+L), Screensaver key, and allows users to define their custom
shortcuts.

I also wonder how many other DEs beside Gnome do not recognize
KEY_SCREENLOCK.

> > > 
> > > This was actually the first path I looked down before I even started the
> > > kernel patch direction for this problem.
> > > 
> > > GNOME doesn't support assigning more than one shortcut key for an action.
> > 
> > So if I want to start calculator on meta+c on internal keyboard, and
> > have calculator button on USB keyboard, I'm out of luck?
> 
> Yeah AFAICT that's the case.
> 
> > 
> > Sounds that should be fixed :-).
> 
> GNOME is commonly known to try to have a very simplistic UX instead of
> exposing more knobs and buttons.
> 
> Adding support for multiple key combinations in a UX means convincing the
> GNOME design team to support this, followed by actual changes.

So there is a simple and wrong way of fixing this (introducing a
hardcoded combination for  shortcut du jour in the kernel) and
complicated one of making one of poplar DEs behave better and be more
flexible. We will not be adding the wrong one to the kernel.

If someone wants to do this kind of translation they are free to have a
tiny uinput daemon.

> 
> > 
> > Alternatively, you can just turn KEY_SCREENLOCK into META+L inside
> > Gnome.
> > 
> > BR,
> > 									Pavel
> 
> Or I can just go back to changing this locally in the PMF driver and it
> works everywhere without needing to convince every userspace to make a
> change to add special mappings.
> 
> As there isn't appetite from input maintainers to have a mapping in the
> input layer I think I'll go that direction for a v5.

I think this would be a mistake. I'll mention that on the other posting.

Thanks.

-- 
Dmitry