Re: [PATCH] [v2] Input: increase max button number to 0x340

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Tomasz,

On Fri, Aug 02, 2024 at 10:09:40PM +0200, Tomasz Pakuła wrote:
> Hi. I can't seem to shake the feeling I'm being ignored here. I would love to 
> get some input from you Dmitry, as this is an issue that was raised a few
> times throught the years and many times, it was left to wither, even with
> proper patches submitted and the reasoning explained.
> 
> One might think of this as trivial, but this is kind of an ancient limitation
> and we ought to improve linux HID compatibility, especially since this is
> such an "easy" fix but still has to propagate throught the linux world.
> 
> If I'm stepping out of the line, or something is really worng with my
> intention here then please let me know, but I know at least in 2020 there
> was a similar push to change this and  after Wei Shuai explained his reasons
> he was similary ignored.
> 
> Me? I just got a new Moza wheel and it too uses button above 80 so I can't
> make proper use of it :)

Sorry, I must have missed Wei's email and I was just trying to figure
out what to do here...

I understand that we have a limitation in the input layer for the number
of keys/buttons to support, but I wonder if input layer is the best way
of going through here. For the long time I was against an "anonymous" or
programmable buttons in the EV_KEY space. The reason is that we want
userspace to not care what device emits an event and act solely upon
what that event is. I.e. if a device emits KEY_A it should not matter if
it is an external USB keyboard, or internal PS/2 one or maybe it is
Chrome OS matrix keyboard connected to an embedded controller with it's
own protocol. Same goes for KEY_SCREENLOCK and others. Yes, we do have
multiple usages called "trigger happy" but I am not really happy about
them.

Additionally extending keys space is not free, we need to allocate
bitmaps, historically we run into issues with uevents being too big,
etc, etc.

I wonder if we can consider following alternatives:

1. Can we go through HID (/dev/hidraw) instead of input layer? I do not
think we will see such devices connected over anything but HID (BT or
USB).

2. Can we consider using something other than EV_KEY? For example we
could define EV_MSC/MSC_PROG_KEY and EV_MSC/MSG_PROG_VAL pair to allow
transmitting key number and state of keys that do not have pre-defined
meaning. Here we are losing event deduplication and ability to query
full keyboard state, but I wonder how important that is for the devices
in question.

Thanks.

-- 
Dmitry