On Fri, Aug 02, 2024 at 04:58:31PM -0700, Dmitry Torokhov wrote: > 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. ftr though it's mostly obvious, this effectively moves all key configuration into the kernel, doubly so for devices that are fully programmable with no specific meanings (the XKeys devices are the oldest ones that I'm aware of that don't work that way). IOW, this approach works for semantic keys but not at all for anything that's really just one key out of many with no real distinguishing features otherwise. OTOH it has saved us from having to ship keyboard models like XKB used to do in userspace. > 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). HID is currently unsuitable for two reasons: we don't have EVIOCREVOKE for hidraw (I need to dust off that patch from years ago). And the desktop input stack (i.e. libinput + compositors) doesn't handle that use-case either, our key events are currently tied to EV_KEY codes. Can be worked around, just needs a fair bit of effort that without a HIDIOCREVOKE (and logind integration) isn't worth starting. But at least for these devices - libinput already doesn't handle joysticks/gaming devices so I can easily ignore those too and let those be punted to the application :) Which means the ioctl is all we need for now? > 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. The same problem rears its head in the EV_ABS and EV_REL range, so fixing it for EV_KEY doesn't necessarily fix it for those. MSC_PROG_KEY/VAL pairs would make it difficult to send two button updates in the same frame without an SYN_MT_REPORT equivalent. but (and this is not fully thought through) if we are ok with dropping value 2 key repeat values we can make the input_event.value a bitmask, so we can have EV_KEYMASK / KEYMASK_00, KEYMASK_32, .... so for buttons 1, 2 and 32 down you'd send EV_KEYMASK / KEYMASK_00 / 3 EV_KEYMASK / KEYMASK_32 / 1 SYN_REPORT This should be nicely map-able from HID too. Would also work for EV_MSC / MSC_PROG_KEYMASK if you don't want a new type. Other random idea, even less thought out: have a marker bit/value that designates anything in a certain range as "merely numbered'. Not sure how to do that but that would make it possible for non-mt devices to re-use the limited abs range for something else. Cheers, Peter
