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
