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

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