On Thu, Aug 08, 2024 at 09:46:09AM +0200, Tomasz Pakuła wrote: > > No, not really. EVIOCGRAB is an ioctl on evdev, as well as > > EVIOCGKEYCODE_V2 and EVIOCSKEYCODE_V2. If you do not care about meaning > > the kernel assigns to the buttons you can remap usages to whatever > > (maybe withing the range of 0x160 - 0x2ff) using EVIOCSKEYCODE_V2, and > > use EVIOCGRAB to stop events being delivered to anything but your > > application (so the rest of the system is not confused). > > > > These are existing userspace APIs that SDL can use. > > But to remap a usage, it would still have to be in range to actually > show up in evdev? I think Dmitry meant that instead of having randomly sprinkled usages you remap every single one sequentially from 1..N, effectively giving you a KEY_MAX number of *physical* buttons. Then you treat them sequentially instead of whatever the #define's name is. > > What do you mean? If we go to separate event namespace then what KEY_MAX > > would have to do with it? > > I guess, in that instance it maybe would not matter, as legacy > software would not > be able to read the new namespace and KEY_MAX wouldn't even be considered > there. > > > > > Would it take that long to teach SDL about new event types (EV_BTN that > > Peter suggested or MSC_KEY* pairs)? > > > > Can we also talk again about the exact use case we need to solve. It is > > not a random Steam game that will make use of tens or hundreds of > > keys/buttons and only support a single input device. Don't you already > > have to deal with let's say racing wheel and pedals being separate > > devices? > > SDL would be easy I think, but there are actually native linux games, > and they, sadly > have their own statically linked SDL versions. Well, nothing we can do > about it really. > > Simracing equipment supports dual mode operation more often than not, to > combat the exact issues of multiple devices. Most of the time, it's recommended > to connect everything through the wheelbase. Moreover, even if such devices are > connected directly through USB, they can still define a lot of buttons > just to keep > the assignments the same. My h-pattern shifter does this, as even when used > standalone, it sends its events in the 112-120 range. > > The use case is I want to use every button that's available to me. My > steering wheel > has 5 rotary knobs, each has 12 states that appear as separate > buttons. This means > they alone define 60 buttons. And even If I wanted to use just one, > the buttons don't > even show up. arguably, those knobs should be defined as an ABS_WHEEL with a range of 0-11 But now we're back at the "we're out of EV_ABS codes" problem which is the older brother of the "we're out of EV_KEY codes" problem :) > Currently additional buttons just overflow into the undefined range and stop at > KEY_MAX, and that's why my first intention was to just increase this > define, as it > would be the fastest fix. > > > I feel we are talking about pretty specialized hardware and pretty > > specialized applications and that is why I was wondering if using HID > > instead of input would not be a better choice here. > > Just Racing simulators, Slight simulators, button boxes of any kind. > Honestly, anything that would make it possible to define and receive > buttons. I just wonder if it would be good to spinn off the whole joystick stuff > so devices like that (gamepads, wheels, etc) would have their own subsystem. > Current stuff could be kept for compatibility reasons, but this new component > would take care of all the events, buttons, ranges. This would be a complete > and singular source of "truth". xkcd too many standards comic :) Cheers, Peter
