On Thu, Aug 08, 2024 at 09:46:09AM +0200, Tomasz Pakuła wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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