On Wed, Aug 07, 2024 at 10:22:13PM +0200, Tomasz Pakuła wrote: > > > > It seems like we're stuck between a rock and a hard place, but at least one > > > > thing makes this easier. Even if a new usage shows up, it doesn't really > > > > matter for games and especially sdl. Given button must just work, and it's > > > > designated usage is of no concern. For all intents and purposes, it's just a > > > > random name that may or may not show up in the binding settings. > > > > > > > > Moreover, all these usages are lost in the proton translation layer, and most > > > > games are played with it's help nowadays. For the Windows games behind wine, > > > > these buttons don't have any special meaning and just have numbers. > > > > They however do have meaning for the rest of the system. SDL clients are > > not only ones who listen to input events, so if we extend the "button > > happy" range we will not be able to use it for anything else, like Peter > > said. > > > > If you do not care about meaning of the events sent out by the kernel > > then maybe you can "grab" the device (EVIOCGRAB) and completely override > > the keymap? Will that will work for you? > > Wouldn't that defeat the whole point of input devices being HID compliant, if > any device that wants to exceed this button range, has to have it's own driver? note that evdev is not HID, you get evdev event nodes for any input device that's supported, regardless what the underlying protocol is. HID is the incoming protocol, evdev is the outgoing protocol and the limitation is in the translation from one to the other because they're not 100% identical. if you want to use HID, you can access the device via the hidraw node but then you also have to do all the actual HID parsing etc. yourself. and openign the hidraw node which currently requires root (or for gaming(-ish) devices on logind an active session). > > > > I guess my point is that if we were to increase these button ranges in ANY > > > > different way than increasing this limit, we would still need massive movement > > > > to get all the software to handle these new cases, if they ever would actually > > > > care/have resources to do so. > > > > Yes, but this is the right thing to do. Otherwise next year you will > > create a joystick with 512 buttons and we will be back to square one. > > After all we though that 40 extra buttons should be more than enough, > > and we were wrong. > > > > Thanks. > > > > -- > > Dmitry > > Wouldn't that defeat the whole point of input devices being HID compliant, if > any device that wants to exceed this button range, has to have it's own driver? > > I just about understand your reasoning, but I assume this would actually take > years to implement across userspace, not mentioning first we would need work > to happen inside kernel, and that would take another bunch of time as this > isn't a priority to just about anyone who would have the actual knowledge to > come up with a sane solution. Not mentioning the fact, that just having BTN_MAX > defined in the first place would rear it's ugly head. It's basically accepted that we need a proper solution for the current evdev restrictions and that has been the case for years. I recall David's ABS_MAX2 patches from 11 years ago: https://lkml.org/lkml/2013/10/2/632 So *something* needs to be done but adding things like BTN_TRIGGER_HAPPY and extending the ranges and filling other bits in just kicks the can down the road another few years until it gets even harder to fix because now we have even more legacy software and hardware to worry about. This really needs someone motivated enough to figure out what to do, but that takes time and effort, at least the former of which is very much in short supply. Either way, the best time to fix this was 10 years ago, the second-best time is now :) Cheers, Peter > Yeas, 512 buttons MIGHT be doable, but the truth is, there are A LOT of devices > with over 80 buttons (and BTN_TRIGGER_HAPPY range actually ends at button 57), > over 140 though? Not so much, if any. Extending BTN_TRIGGER_HAPPY range by > another 60 usages is just THE fix for current state of input. If it is just > too ugly then I guess that's that. Sadly, it would seem that this issue > won't be resolved for years in that case. 2030? > > Though, at some point, there won't be any more space for new key codes and > BTN_MAX will have to be increased no matter what. > > At least I gathered some much needed info and insight. Still compiling my own > kernel every time is not something I look for :/ > > Respectfully > Tomasz
