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

[Peter Hutterer <peter.hutterer@who-t.net>]

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