linux-kernel - Re: [PATCH v2 1/2] Input: allocate a keycode for Fn+space

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: <175826663475.18450.7037268164142228744@lain.khirnov.net>
Date: Fri, 19 Sep 2025 09:23:54 +0200
From:  Anton Khirnov <anton@...rnov.net>
To:  Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:  Corentin Chary <corentin.chary@...il.com>,
 "Luke D. Jones" <luke@...nes.dev>, Hans de Goede <hansg@...nel.org>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-input@...r.kernel.org
Subject:  Re: [PATCH v2 1/2] Input: allocate a keycode for Fn+space

Hi Dmitry,
Quoting Dmitry Torokhov (2025-09-19 07:12:38)
> Hi Anton,
> 
> On Mon, Jul 14, 2025 at 05:07:57PM +0200, Anton Khirnov wrote:
> > The Asus ExpertBook B9 laptop sends a WMI event when Fn+space is
> > pressed. Since I could not find any information on what this combination
> > is intended to do on this or any other Asus laptop, allocate a
> > KEY_FN_SPACE keycode for it.
> > 
> > Signed-off-by: Anton Khirnov <anton@...rnov.net>
> > ---
> >  include/uapi/linux/input-event-codes.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> > index 3b2524e4b667..a49b0782fd8a 100644
> > --- a/include/uapi/linux/input-event-codes.h
> > +++ b/include/uapi/linux/input-event-codes.h
> > @@ -548,6 +548,7 @@
> >  #define KEY_FN_S		0x1e3
> >  #define KEY_FN_B		0x1e4
> >  #define KEY_FN_RIGHT_SHIFT	0x1e5
> > +#define KEY_FN_SPACE		0x1e6
> 
> I'd rather we did not add more codes with no defined meaning. I regret
> that we have KEY_FN_* (with the exception of KEY_FN itself). Since
> nobody knows what this key is supposed to do maybe map it to
> KEY_RESERVED and whoever wants to use it can map it to a concrete key
> code via udev?

The problem with that approach is that on this laptop we have TWO keys
with unknown meanings - fn+space and fn+f (KEY_FN_F already exists).
Using KEY_RESERVED for one of them would be inconsistent then.

Could you elaborate on why are you against KEY_FN_* codes? I understand
they can be abused, but in some cases (such as this one) it genuinely
seems the least bad way to characterize a key.

Cheers,
-- 
Anton Khirnov