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

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

[Tomasz Pakuła]

v1 of this patch increased the number of buttons to 0x3ff. This version
reduces this number to 0x340 to decrease the size of some static arrays
by almost 200.

Maximum number of buttons is limited to 0x2ff. This makes it so game
controllers like joysticks, racing wheelbases etc. are limited to 80
buttons.

A lot of input devices for flight simulators and racing simulators take
full advantage of defining a large number of buttons in HID descriptor,
in turn, some of their buttons simply don't show up under linux. Linux
became quite a viable gaming platform in the recent years so this makes
it so it supports all the HID peripherals without fuss and confusion
(there aren't any dmesg errors if HID device exceeds the 0x2ff
button id).

I'm a part of linux simracing community and we encoutered this issue
with Moza Racing wheelbases, as they use top of the range for things
like h-pattern shifters, sequential shifters. These accessories simply
don't work, be it connected through the wheelbase or directly with USB.

Upcoming Moza Flight Sim devices will face the same issue, and there
were Saitek/Logitech/Honeycomb and custom-made products that also have
more than 80 buttons.

0x2ff was already sort of an arbitrary number, I'm increasing it to
0x340 to still keep the array not too big, while allowing additional 65
buttons.

Change has been verified on my Moza Racing R9 wheelbase + Moza racing
sequential shifter (it uses buttons 112-117). I didn't encounter any
issues whatsoever. Evey button works, every axis works. Keyboards and
other peripherals unaffected.

This patch is important as SDL uses this defines and we'll have to
wait until it propagates into release versions built on top of
(hopefully) 6.11

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
 include/linux/mod_devicetable.h        | 2 +-
 include/uapi/linux/input-event-codes.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 4338b1b4ac44..e1699f4b1858 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -333,7 +333,7 @@ struct pcmcia_device_id {
 /* Input */
 #define INPUT_DEVICE_ID_EV_MAX		0x1f
 #define INPUT_DEVICE_ID_KEY_MIN_INTERESTING	0x71
-#define INPUT_DEVICE_ID_KEY_MAX		0x2ff
+#define INPUT_DEVICE_ID_KEY_MAX		0x340
 #define INPUT_DEVICE_ID_REL_MAX		0x0f
 #define INPUT_DEVICE_ID_ABS_MAX		0x3f
 #define INPUT_DEVICE_ID_MSC_MAX		0x07
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index a4206723f503..5f10f09ac174 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -808,7 +808,7 @@
 
 /* We avoid low common keys in module aliases so they don't get huge. */
 #define KEY_MIN_INTERESTING	KEY_MUTE
-#define KEY_MAX			0x2ff
+#define KEY_MAX			0x340
 #define KEY_CNT			(KEY_MAX+1)
 
 /*
-- 
2.45.2

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

[Tomasz Pakuła]

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 :)

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

[Dmitry Torokhov]

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.

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).

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.

Thanks.

-- 
Dmitry

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

[Peter Hutterer]

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

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

[Tomasz Pakuła]

On Mon, 5 Aug 2024 at 07:34, Peter Hutterer <peter.hutterer@who-t.net> wrote:
>
> 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

Hmm, these all sound like good ideas. I'm net yet very well versed in the whole
linux kernel input stack, but looking at it, it seems that it does need an
overhaul in the coming years.

But I have some questions. This patch only adds another 65 possible buttons/
undefined usages. Would it really pose such an issue? 0x2ff already is quite
a big number (767). I don't think another 65 would really break the bank here.

> Additionally extending keys space is not free, we need to allocate
> bitmaps, historically we run into issues with uevents being too big,
> etc, etc.

Is it related to Linux kernel or outside software? Is linux generating some
kind of bitmaps? I'm not aware of such thing.

Peter's idea seems sane BUT doesn't address the real crutch here. A lot of
software uses (directly, or indirectly) KEY_MAX define to outright cap the
number of buttons read from a given HID device. From the top of my head,
SDL2/3 does this, Firefox as well.

When it comes to undefined usages, software already deals with that without
issues. For years we had this undefined range above TRIGGER_HAPPY_40 from
0x2e8 to 0x2ff. SDL returns "Undefined" name, evtest marks these as "?" BUT
this doesn't impare the use of such buttons in the slightest. These simply
show up as buttons 58-80.

All in all, we've had people using this patch (but increasing KEY_MAX to a
whopping 0x4ff) for the past few years with no adverse effects. I've been
using a custom Linux kernel with this patch on my Arch machine since about
May, and didn't notice anything, even when compiling with debug flags and
following and filtering dmesg.

So here's the thing I'm most curious about. Is this something, you'd just
want to resolve differently, to make it nicer and more logical, or is this
really something that would break everything and doing it in this way will
never be allowed/merged? That would make a lot of us sad :(

Thanks, and cheers
Tomasz

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

[Peter Hutterer]

On Tue, Aug 06, 2024 at 07:50:07PM +0200, Tomasz Pakuła wrote:
> On Mon, 5 Aug 2024 at 07:34, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> >
> > 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
> 
> Hmm, these all sound like good ideas. I'm net yet very well versed in the whole
> linux kernel input stack, but looking at it, it seems that it does need an
> overhaul in the coming years.
> 
> But I have some questions. This patch only adds another 65 possible buttons/
> undefined usages. Would it really pose such an issue? 0x2ff already is quite
> a big number (767). I don't think another 65 would really break the bank here.
> 
> > Additionally extending keys space is not free, we need to allocate
> > bitmaps, historically we run into issues with uevents being too big,
> > etc, etc.
> 
> Is it related to Linux kernel or outside software? Is linux generating some
> kind of bitmaps? I'm not aware of such thing.

Recent example I recall is this:
https://lore.kernel.org/lkml/ZjAWMQCJdrxZkvkB@google.com/t/

> Peter's idea seems sane BUT doesn't address the real crutch here. A lot of
> software uses (directly, or indirectly) KEY_MAX define to outright cap the
> number of buttons read from a given HID device. From the top of my head,
> SDL2/3 does this, Firefox as well.

fwiw, anything based on libevdev which is at least libinput +
xf86-input-synaptics/evdev are similarly capped.

> When it comes to undefined usages, software already deals with that without
> issues. For years we had this undefined range above TRIGGER_HAPPY_40 from
> 0x2e8 to 0x2ff. SDL returns "Undefined" name, evtest marks these as "?" BUT
> this doesn't impare the use of such buttons in the slightest. These simply
> show up as buttons 58-80.

ftr, evtest marks anything as ? that doesn't have a define added to
evdev. libevdev does the same but at least it automates the process
based on the kernel header file.

But my main gripe here is that, for better of worse, the keycodes
are semantic - an unknown code isn't "button N" because in the next
kernel version it may be e.g. KEY_VOLUME_MAX and unless you special-case
every client that wants to use your device, this hurts. At
least the trigger happy is reserved to never be anything else.

Likewise, once released your device will now *always* have to send
KEY_VOLUME_MAX for button 3 because changing that will break everyone
special-casing your device.

We have existing instances like this: BTN_BACK and BTN_FORWARD are not
actually forward/back because decades ago X decided physical buttons 4
and 5 have that role - so BTN_SIDE/EXTGRA are mapped to back/forward and
BTN_FORWARD/BACK are mapped to whatever comes next (also note: X and
thus the rest of userspace has back/forward whereas the kernel has
forward/back).

libevdev (and thus libinput/xorg drivers) have special casing for
ABS_MT_SLOT - 1 to detect "fake" multitouch devices that just run up
from the ABS_MISC range.

etc. etc.

Cheers,
  Peter

PS: and re-reading the above I realised it would also be relatively
trivial to add EV_BTN. That could (maybe?) even run parallel to EV_KEY
in the same frame so that button 8 becomes something like:

	EV_KEY BTN_FOO 1
	EV_BTN 8 1
	EV_SYN SYN_REPORT

Which means that userspace becomes a "if EV_BTN is present, ignore the
EV_KEY in the same frame" though that gets a bit trickier if we have
more than one per frame.


> All in all, we've had people using this patch (but increasing KEY_MAX to a
> whopping 0x4ff) for the past few years with no adverse effects. I've been
> using a custom Linux kernel with this patch on my Arch machine since about
> May, and didn't notice anything, even when compiling with debug flags and
> following and filtering dmesg.
> 
> So here's the thing I'm most curious about. Is this something, you'd just
> want to resolve differently, to make it nicer and more logical, or is this
> really something that would break everything and doing it in this way will
> never be allowed/merged? That would make a lot of us sad :(
> 
> Thanks, and cheers
> Tomasz

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

[Dmitry Torokhov]

On Wed, Aug 07, 2024 at 01:12:45PM +1000, Peter Hutterer wrote:
> On Tue, Aug 06, 2024 at 07:50:07PM +0200, Tomasz Pakuła wrote:
> > On Mon, 5 Aug 2024 at 07:34, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > >
> > > 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.

I do not think that frame notion is that important for keys. It is
typically important for a pointing device state.

> > >
> > > 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
> > 
> > Hmm, these all sound like good ideas. I'm net yet very well versed in the whole
> > linux kernel input stack, but looking at it, it seems that it does need an
> > overhaul in the coming years.
> > 
> > But I have some questions. This patch only adds another 65 possible buttons/
> > undefined usages. Would it really pose such an issue? 0x2ff already is quite
> > a big number (767). I don't think another 65 would really break the bank here.
> > 
> > > Additionally extending keys space is not free, we need to allocate
> > > bitmaps, historically we run into issues with uevents being too big,
> > > etc, etc.
> > 
> > Is it related to Linux kernel or outside software? Is linux generating some
> > kind of bitmaps? I'm not aware of such thing.
> 
> Recent example I recall is this:
> https://lore.kernel.org/lkml/ZjAWMQCJdrxZkvkB@google.com/t/

Yes. Also we present input device capabilities in sysfs and /proc and
potentially other places.

> 
> > Peter's idea seems sane BUT doesn't address the real crutch here. A lot of
> > software uses (directly, or indirectly) KEY_MAX define to outright cap the
> > number of buttons read from a given HID device. From the top of my head,
> > SDL2/3 does this, Firefox as well.
> 
> fwiw, anything based on libevdev which is at least libinput +
> xf86-input-synaptics/evdev are similarly capped.
> 
> > When it comes to undefined usages, software already deals with that without
> > issues. For years we had this undefined range above TRIGGER_HAPPY_40 from
> > 0x2e8 to 0x2ff. SDL returns "Undefined" name, evtest marks these as "?" BUT
> > this doesn't impare the use of such buttons in the slightest. These simply
> > show up as buttons 58-80.
> 
> ftr, evtest marks anything as ? that doesn't have a define added to
> evdev. libevdev does the same but at least it automates the process
> based on the kernel header file.
> 
> But my main gripe here is that, for better of worse, the keycodes
> are semantic - an unknown code isn't "button N" because in the next
> kernel version it may be e.g. KEY_VOLUME_MAX and unless you special-case
> every client that wants to use your device, this hurts. At
> least the trigger happy is reserved to never be anything else.

Exactly.

> 
> Likewise, once released your device will now *always* have to send
> KEY_VOLUME_MAX for button 3 because changing that will break everyone
> special-casing your device.
> 
> We have existing instances like this: BTN_BACK and BTN_FORWARD are not
> actually forward/back because decades ago X decided physical buttons 4
> and 5 have that role - so BTN_SIDE/EXTGRA are mapped to back/forward and
> BTN_FORWARD/BACK are mapped to whatever comes next (also note: X and
> thus the rest of userspace has back/forward whereas the kernel has
> forward/back).
> 
> libevdev (and thus libinput/xorg drivers) have special casing for
> ABS_MT_SLOT - 1 to detect "fake" multitouch devices that just run up
> from the ABS_MISC range.
> 
> etc. etc.
> 
> Cheers,
>   Peter
> 
> PS: and re-reading the above I realised it would also be relatively
> trivial to add EV_BTN. That could (maybe?) even run parallel to EV_KEY
> in the same frame so that button 8 becomes something like:
> 
> 	EV_KEY BTN_FOO 1
> 	EV_BTN 8 1
> 	EV_SYN SYN_REPORT
> 
> Which means that userspace becomes a "if EV_BTN is present, ignore the
> EV_KEY in the same frame" though that gets a bit trickier if we have
> more than one per frame.
> 
> 
> > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > using a custom Linux kernel with this patch on my Arch machine since about
> > May, and didn't notice anything, even when compiling with debug flags and
> > following and filtering dmesg.
> > 
> > So here's the thing I'm most curious about. Is this something, you'd just
> > want to resolve differently, to make it nicer and more logical, or is this
> > really something that would break everything and doing it in this way will
> > never be allowed/merged? That would make a lot of us sad :(

We need to figure out not only how to handle your class of devices, but
also allow extending number of keys that do have certain semantic
meaning. Peter raised a lot of questions that we need to answer.

But I wonder, these devices with large number of buttons that do not
have predefined meaning - do they have to be a single input device? Can
we create N input devices if we exceed the "trigger happy" range, all of
them mapping to "trigger happy"? That would mean that userspace would
keep track of key assignment on per-device basis.

We already split HID devices on per-apllication (not userspace but HID
application) basis, and also when there are several USB interfaces.

Thanks.

-- 
Dmitry

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

[Peter Hutterer]

On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:
> > > > > 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.
> 
> I do not think that frame notion is that important for keys. It is
> typically important for a pointing device state.

true, I remember a conversation years back that frames aren't
consistently implemented in keyboard drivers anyway which is the reason
libinput sends (most) EV_KEY events immediately instad of waiting for a
SYN_REPORT.

> > > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > > using a custom Linux kernel with this patch on my Arch machine since about
> > > May, and didn't notice anything, even when compiling with debug flags and
> > > following and filtering dmesg.
> > > 
> > > So here's the thing I'm most curious about. Is this something, you'd just
> > > want to resolve differently, to make it nicer and more logical, or is this
> > > really something that would break everything and doing it in this way will
> > > never be allowed/merged? That would make a lot of us sad :(
> 
> We need to figure out not only how to handle your class of devices, but
> also allow extending number of keys that do have certain semantic
> meaning. Peter raised a lot of questions that we need to answer.
> 
> But I wonder, these devices with large number of buttons that do not
> have predefined meaning - do they have to be a single input device? Can
> we create N input devices if we exceed the "trigger happy" range, all of
> them mapping to "trigger happy"? That would mean that userspace would
> keep track of key assignment on per-device basis.
> 
> We already split HID devices on per-apllication (not userspace but HID
> application) basis, and also when there are several USB interfaces.

Honestly, I'd vote against this.
re-combining input devices into a single device in userspace is a pain.
The split per application in HID is mostly fine because they're
usually physically different devices but I recently ran into the issue
with the uclogic drivers where various features are split across
event nodes. Thse devices have the ring on one event node, the buttons
on another, etc. Nothing in (my) userspace is currently set up for this
and it'd require a major rework in many places to be able to handle this
properly. And it requires that rework in every userspace stack, possibly
special-cased on a vendor id. In the end it was easier (re-)writing BPFs
to get the expected event node behaviour than dealing with the split.

A device that arbitrarily splits makes this even more difficult - which
one of the event nodes has buttons 1-20 and which one has 21-40? We'd need
some other magic somewhere (e.g. hiding in uniq) and some digging around
in udev to figure out which ones are part of the same device.

I'd rather not go with a simple-for-now solution that makes everything
in userspace more complicated, forever.

Cheers,
  Peter

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

[Tomasz Pakuła]

On Wed, 7 Aug 2024 at 07:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
>
> On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:
> > > > > > 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.
> >
> > I do not think that frame notion is that important for keys. It is
> > typically important for a pointing device state.
>
> true, I remember a conversation years back that frames aren't
> consistently implemented in keyboard drivers anyway which is the reason
> libinput sends (most) EV_KEY events immediately instad of waiting for a
> SYN_REPORT.
>
> > > > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > > > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > > > using a custom Linux kernel with this patch on my Arch machine since about
> > > > May, and didn't notice anything, even when compiling with debug flags and
> > > > following and filtering dmesg.
> > > >
> > > > So here's the thing I'm most curious about. Is this something, you'd just
> > > > want to resolve differently, to make it nicer and more logical, or is this
> > > > really something that would break everything and doing it in this way will
> > > > never be allowed/merged? That would make a lot of us sad :(
> >
> > We need to figure out not only how to handle your class of devices, but
> > also allow extending number of keys that do have certain semantic
> > meaning. Peter raised a lot of questions that we need to answer.
> >
> > But I wonder, these devices with large number of buttons that do not
> > have predefined meaning - do they have to be a single input device? Can
> > we create N input devices if we exceed the "trigger happy" range, all of
> > them mapping to "trigger happy"? That would mean that userspace would
> > keep track of key assignment on per-device basis.
> >
> > We already split HID devices on per-apllication (not userspace but HID
> > application) basis, and also when there are several USB interfaces.
>
> Honestly, I'd vote against this.
> re-combining input devices into a single device in userspace is a pain.
> The split per application in HID is mostly fine because they're
> usually physically different devices but I recently ran into the issue
> with the uclogic drivers where various features are split across
> event nodes. Thse devices have the ring on one event node, the buttons
> on another, etc. Nothing in (my) userspace is currently set up for this
> and it'd require a major rework in many places to be able to handle this
> properly. And it requires that rework in every userspace stack, possibly
> special-cased on a vendor id. In the end it was easier (re-)writing BPFs
> to get the expected event node behaviour than dealing with the split.
>
> A device that arbitrarily splits makes this even more difficult - which
> one of the event nodes has buttons 1-20 and which one has 21-40? We'd need
> some other magic somewhere (e.g. hiding in uniq) and some digging around
> in udev to figure out which ones are part of the same device.
>
> I'd rather not go with a simple-for-now solution that makes everything
> in userspace more complicated, forever.
>
> Cheers,
>   Peter

Yes, I would also say splitting is, unfortunately, out of the question, because
of the intended use-case of joysticks and other gaming devices. Most games do
not handle multiple inputs and only allow for one device to be set up at the
same time. This means, any buttons not present on the first device would simply
be inaccessible and the end result would be the same as now.

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.

While I understand that a new usage might show up someday, I wonder how
likely it is in the near future. TRIGGER_HAPPY range was added about 20 years
ago? For me, as a 27 year old it seems like a lifetime ago.

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.

Tomasz

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

[Wei Shuai]

yes, agree. either way, will be a revolution.

At least, for me as X-Plane flight simulator gamer, a small change in
expanding the key max number can make my device work immediately

Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> 于2024年8月7日周三 14:23写道：
>
> On Wed, 7 Aug 2024 at 07:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> >
> > On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:
> > > > > > > 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.
> > >
> > > I do not think that frame notion is that important for keys. It is
> > > typically important for a pointing device state.
> >
> > true, I remember a conversation years back that frames aren't
> > consistently implemented in keyboard drivers anyway which is the reason
> > libinput sends (most) EV_KEY events immediately instad of waiting for a
> > SYN_REPORT.
> >
> > > > > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > > > > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > > > > using a custom Linux kernel with this patch on my Arch machine since about
> > > > > May, and didn't notice anything, even when compiling with debug flags and
> > > > > following and filtering dmesg.
> > > > >
> > > > > So here's the thing I'm most curious about. Is this something, you'd just
> > > > > want to resolve differently, to make it nicer and more logical, or is this
> > > > > really something that would break everything and doing it in this way will
> > > > > never be allowed/merged? That would make a lot of us sad :(
> > >
> > > We need to figure out not only how to handle your class of devices, but
> > > also allow extending number of keys that do have certain semantic
> > > meaning. Peter raised a lot of questions that we need to answer.
> > >
> > > But I wonder, these devices with large number of buttons that do not
> > > have predefined meaning - do they have to be a single input device? Can
> > > we create N input devices if we exceed the "trigger happy" range, all of
> > > them mapping to "trigger happy"? That would mean that userspace would
> > > keep track of key assignment on per-device basis.
> > >
> > > We already split HID devices on per-apllication (not userspace but HID
> > > application) basis, and also when there are several USB interfaces.
> >
> > Honestly, I'd vote against this.
> > re-combining input devices into a single device in userspace is a pain.
> > The split per application in HID is mostly fine because they're
> > usually physically different devices but I recently ran into the issue
> > with the uclogic drivers where various features are split across
> > event nodes. Thse devices have the ring on one event node, the buttons
> > on another, etc. Nothing in (my) userspace is currently set up for this
> > and it'd require a major rework in many places to be able to handle this
> > properly. And it requires that rework in every userspace stack, possibly
> > special-cased on a vendor id. In the end it was easier (re-)writing BPFs
> > to get the expected event node behaviour than dealing with the split.
> >
> > A device that arbitrarily splits makes this even more difficult - which
> > one of the event nodes has buttons 1-20 and which one has 21-40? We'd need
> > some other magic somewhere (e.g. hiding in uniq) and some digging around
> > in udev to figure out which ones are part of the same device.
> >
> > I'd rather not go with a simple-for-now solution that makes everything
> > in userspace more complicated, forever.
> >
> > Cheers,
> >   Peter
>
> Yes, I would also say splitting is, unfortunately, out of the question, because
> of the intended use-case of joysticks and other gaming devices. Most games do
> not handle multiple inputs and only allow for one device to be set up at the
> same time. This means, any buttons not present on the first device would simply
> be inaccessible and the end result would be the same as now.
>
> 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.
>
> While I understand that a new usage might show up someday, I wonder how
> likely it is in the near future. TRIGGER_HAPPY range was added about 20 years
> ago? For me, as a 27 year old it seems like a lifetime ago.
>
> 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.
>
> Tomasz

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

[Dmitry Torokhov]

On Wed, Aug 07, 2024 at 04:42:56PM +0800, Wei Shuai wrote:
> yes, agree. either way, will be a revolution.
> 
> At least, for me as X-Plane flight simulator gamer, a small change in
> expanding the key max number can make my device work immediately
> 
> Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> 于2024年8月7日周三 14:23写道：
> >
> > On Wed, 7 Aug 2024 at 07:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > >
> > > On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:
> > > > > > > > 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.
> > > >
> > > > I do not think that frame notion is that important for keys. It is
> > > > typically important for a pointing device state.
> > >
> > > true, I remember a conversation years back that frames aren't
> > > consistently implemented in keyboard drivers anyway which is the reason
> > > libinput sends (most) EV_KEY events immediately instad of waiting for a
> > > SYN_REPORT.
> > >
> > > > > > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > > > > > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > > > > > using a custom Linux kernel with this patch on my Arch machine since about
> > > > > > May, and didn't notice anything, even when compiling with debug flags and
> > > > > > following and filtering dmesg.
> > > > > >
> > > > > > So here's the thing I'm most curious about. Is this something, you'd just
> > > > > > want to resolve differently, to make it nicer and more logical, or is this
> > > > > > really something that would break everything and doing it in this way will
> > > > > > never be allowed/merged? That would make a lot of us sad :(
> > > >
> > > > We need to figure out not only how to handle your class of devices, but
> > > > also allow extending number of keys that do have certain semantic
> > > > meaning. Peter raised a lot of questions that we need to answer.
> > > >
> > > > But I wonder, these devices with large number of buttons that do not
> > > > have predefined meaning - do they have to be a single input device? Can
> > > > we create N input devices if we exceed the "trigger happy" range, all of
> > > > them mapping to "trigger happy"? That would mean that userspace would
> > > > keep track of key assignment on per-device basis.
> > > >
> > > > We already split HID devices on per-apllication (not userspace but HID
> > > > application) basis, and also when there are several USB interfaces.
> > >
> > > Honestly, I'd vote against this.
> > > re-combining input devices into a single device in userspace is a pain.
> > > The split per application in HID is mostly fine because they're
> > > usually physically different devices but I recently ran into the issue
> > > with the uclogic drivers where various features are split across
> > > event nodes. Thse devices have the ring on one event node, the buttons
> > > on another, etc. Nothing in (my) userspace is currently set up for this
> > > and it'd require a major rework in many places to be able to handle this
> > > properly. And it requires that rework in every userspace stack, possibly
> > > special-cased on a vendor id. In the end it was easier (re-)writing BPFs
> > > to get the expected event node behaviour than dealing with the split.
> > >
> > > A device that arbitrarily splits makes this even more difficult - which
> > > one of the event nodes has buttons 1-20 and which one has 21-40? We'd need
> > > some other magic somewhere (e.g. hiding in uniq) and some digging around
> > > in udev to figure out which ones are part of the same device.
> > >
> > > I'd rather not go with a simple-for-now solution that makes everything
> > > in userspace more complicated, forever.
> > >
> > > Cheers,
> > >   Peter
> >
> > Yes, I would also say splitting is, unfortunately, out of the question, because
> > of the intended use-case of joysticks and other gaming devices. Most games do
> > not handle multiple inputs and only allow for one device to be set up at the
> > same time. This means, any buttons not present on the first device would simply
> > be inaccessible and the end result would be the same as now.

So how does this work with, for example, DualShock controllers. IIRC
they are split into several sub-devices, such as game controller itself,
accelerometer piece, and touchpad piece.

> >
> > 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?

> >
> > While I understand that a new usage might show up someday, I wonder how
> > likely it is in the near future.

dtor@dtor-ws:~/kernel/work $ git log --oneline --since=01-01-2024 -- include/uapi/linux/input-event-codes.h
22d6d060ac77 input: Add support for "Do Not Disturb"
0c7dd00de018 input: Add event code for accessibility key
cfeb98b95fff Input: allocate keycode for Display refresh rate toggle

3 new ones since the beginning of the year.


> > TRIGGER_HAPPY range was added about 20 years
> > ago? For me, as a 27 year old it seems like a lifetime ago.

2010 so only 14 years ;)

> >
> > 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

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

[Tomasz Pakuła]

On Wed, 7 Aug 2024 at 21:01, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> On Wed, Aug 07, 2024 at 04:42:56PM +0800, Wei Shuai wrote:
> > yes, agree. either way, will be a revolution.
> >
> > At least, for me as X-Plane flight simulator gamer, a small change in
> > expanding the key max number can make my device work immediately
> >
> > Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> 于2024年8月7日周三 14:23写道：
> > >
> > > On Wed, 7 Aug 2024 at 07:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > > >
> > > > On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:
> > > > > > > > > 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.
> > > > >
> > > > > I do not think that frame notion is that important for keys. It is
> > > > > typically important for a pointing device state.
> > > >
> > > > true, I remember a conversation years back that frames aren't
> > > > consistently implemented in keyboard drivers anyway which is the reason
> > > > libinput sends (most) EV_KEY events immediately instad of waiting for a
> > > > SYN_REPORT.
> > > >
> > > > > > > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > > > > > > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > > > > > > using a custom Linux kernel with this patch on my Arch machine since about
> > > > > > > May, and didn't notice anything, even when compiling with debug flags and
> > > > > > > following and filtering dmesg.
> > > > > > >
> > > > > > > So here's the thing I'm most curious about. Is this something, you'd just
> > > > > > > want to resolve differently, to make it nicer and more logical, or is this
> > > > > > > really something that would break everything and doing it in this way will
> > > > > > > never be allowed/merged? That would make a lot of us sad :(
> > > > >
> > > > > We need to figure out not only how to handle your class of devices, but
> > > > > also allow extending number of keys that do have certain semantic
> > > > > meaning. Peter raised a lot of questions that we need to answer.
> > > > >
> > > > > But I wonder, these devices with large number of buttons that do not
> > > > > have predefined meaning - do they have to be a single input device? Can
> > > > > we create N input devices if we exceed the "trigger happy" range, all of
> > > > > them mapping to "trigger happy"? That would mean that userspace would
> > > > > keep track of key assignment on per-device basis.
> > > > >
> > > > > We already split HID devices on per-apllication (not userspace but HID
> > > > > application) basis, and also when there are several USB interfaces.
> > > >
> > > > Honestly, I'd vote against this.
> > > > re-combining input devices into a single device in userspace is a pain.
> > > > The split per application in HID is mostly fine because they're
> > > > usually physically different devices but I recently ran into the issue
> > > > with the uclogic drivers where various features are split across
> > > > event nodes. Thse devices have the ring on one event node, the buttons
> > > > on another, etc. Nothing in (my) userspace is currently set up for this
> > > > and it'd require a major rework in many places to be able to handle this
> > > > properly. And it requires that rework in every userspace stack, possibly
> > > > special-cased on a vendor id. In the end it was easier (re-)writing BPFs
> > > > to get the expected event node behaviour than dealing with the split.
> > > >
> > > > A device that arbitrarily splits makes this even more difficult - which
> > > > one of the event nodes has buttons 1-20 and which one has 21-40? We'd need
> > > > some other magic somewhere (e.g. hiding in uniq) and some digging around
> > > > in udev to figure out which ones are part of the same device.
> > > >
> > > > I'd rather not go with a simple-for-now solution that makes everything
> > > > in userspace more complicated, forever.
> > > >
> > > > Cheers,
> > > >   Peter
> > >
> > > Yes, I would also say splitting is, unfortunately, out of the question, because
> > > of the intended use-case of joysticks and other gaming devices. Most games do
> > > not handle multiple inputs and only allow for one device to be set up at the
> > > same time. This means, any buttons not present on the first device would simply
> > > be inaccessible and the end result would be the same as now.
>
> So how does this work with, for example, DualShock controllers. IIRC
> they are split into several sub-devices, such as game controller itself,
> accelerometer piece, and touchpad piece.

Touchpad is easy as it's just a generic mouse. It just works as any other mouse.
Accelerometer can be dealt with Steam input/or maybe emulator that supports
gyro. But TBH, many games would just not support both gyro and buttons for
this reason. Fortunately, most games that actually need this gyro functionality
would be emulated as they're most likely Nintendo titles.

>
> > >
> > > 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?

>
> > >
> > > While I understand that a new usage might show up someday, I wonder how
> > > likely it is in the near future.
>
> dtor@dtor-ws:~/kernel/work $ git log --oneline --since=01-01-2024 -- include/uapi/linux/input-event-codes.h
> 22d6d060ac77 input: Add support for "Do Not Disturb"
> 0c7dd00de018 input: Add event code for accessibility key
> cfeb98b95fff Input: allocate keycode for Display refresh rate toggle
>
> 3 new ones since the beginning of the year.
>
>
> > > TRIGGER_HAPPY range was added about 20 years
> > > ago? For me, as a 27 year old it seems like a lifetime ago.
>
> 2010 so only 14 years ;)
>
> > >
> > > 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.

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

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

[Dmitry Torokhov]

On Wed, Aug 07, 2024 at 10:22:13PM +0200, Tomasz Pakuła wrote:
> On Wed, 7 Aug 2024 at 21:01, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > On Wed, Aug 07, 2024 at 04:42:56PM +0800, Wei Shuai wrote:
> > > yes, agree. either way, will be a revolution.
> > >
> > > At least, for me as X-Plane flight simulator gamer, a small change in
> > > expanding the key max number can make my device work immediately
> > >
> > > Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> 于2024年8月7日周三 14:23写道：
> > > >
> > > > On Wed, 7 Aug 2024 at 07:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > > > >
> > > > > On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:
> > > > > > > > > > 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.
> > > > > >
> > > > > > I do not think that frame notion is that important for keys. It is
> > > > > > typically important for a pointing device state.
> > > > >
> > > > > true, I remember a conversation years back that frames aren't
> > > > > consistently implemented in keyboard drivers anyway which is the reason
> > > > > libinput sends (most) EV_KEY events immediately instad of waiting for a
> > > > > SYN_REPORT.
> > > > >
> > > > > > > > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > > > > > > > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > > > > > > > using a custom Linux kernel with this patch on my Arch machine since about
> > > > > > > > May, and didn't notice anything, even when compiling with debug flags and
> > > > > > > > following and filtering dmesg.
> > > > > > > >
> > > > > > > > So here's the thing I'm most curious about. Is this something, you'd just
> > > > > > > > want to resolve differently, to make it nicer and more logical, or is this
> > > > > > > > really something that would break everything and doing it in this way will
> > > > > > > > never be allowed/merged? That would make a lot of us sad :(
> > > > > >
> > > > > > We need to figure out not only how to handle your class of devices, but
> > > > > > also allow extending number of keys that do have certain semantic
> > > > > > meaning. Peter raised a lot of questions that we need to answer.
> > > > > >
> > > > > > But I wonder, these devices with large number of buttons that do not
> > > > > > have predefined meaning - do they have to be a single input device? Can
> > > > > > we create N input devices if we exceed the "trigger happy" range, all of
> > > > > > them mapping to "trigger happy"? That would mean that userspace would
> > > > > > keep track of key assignment on per-device basis.
> > > > > >
> > > > > > We already split HID devices on per-apllication (not userspace but HID
> > > > > > application) basis, and also when there are several USB interfaces.
> > > > >
> > > > > Honestly, I'd vote against this.
> > > > > re-combining input devices into a single device in userspace is a pain.
> > > > > The split per application in HID is mostly fine because they're
> > > > > usually physically different devices but I recently ran into the issue
> > > > > with the uclogic drivers where various features are split across
> > > > > event nodes. Thse devices have the ring on one event node, the buttons
> > > > > on another, etc. Nothing in (my) userspace is currently set up for this
> > > > > and it'd require a major rework in many places to be able to handle this
> > > > > properly. And it requires that rework in every userspace stack, possibly
> > > > > special-cased on a vendor id. In the end it was easier (re-)writing BPFs
> > > > > to get the expected event node behaviour than dealing with the split.
> > > > >
> > > > > A device that arbitrarily splits makes this even more difficult - which
> > > > > one of the event nodes has buttons 1-20 and which one has 21-40? We'd need
> > > > > some other magic somewhere (e.g. hiding in uniq) and some digging around
> > > > > in udev to figure out which ones are part of the same device.
> > > > >
> > > > > I'd rather not go with a simple-for-now solution that makes everything
> > > > > in userspace more complicated, forever.
> > > > >
> > > > > Cheers,
> > > > >   Peter
> > > >
> > > > Yes, I would also say splitting is, unfortunately, out of the question, because
> > > > of the intended use-case of joysticks and other gaming devices. Most games do
> > > > not handle multiple inputs and only allow for one device to be set up at the
> > > > same time. This means, any buttons not present on the first device would simply
> > > > be inaccessible and the end result would be the same as now.
> >
> > So how does this work with, for example, DualShock controllers. IIRC
> > they are split into several sub-devices, such as game controller itself,
> > accelerometer piece, and touchpad piece.
> 
> Touchpad is easy as it's just a generic mouse. It just works as any other mouse.
> Accelerometer can be dealt with Steam input/or maybe emulator that supports
> gyro. But TBH, many games would just not support both gyro and buttons for
> this reason. Fortunately, most games that actually need this gyro functionality
> would be emulated as they're most likely Nintendo titles.
> 
> >
> > > >
> > > > 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?

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.

> 
> >
> > > >
> > > > While I understand that a new usage might show up someday, I wonder how
> > > > likely it is in the near future.
> >
> > dtor@dtor-ws:~/kernel/work $ git log --oneline --since=01-01-2024 -- include/uapi/linux/input-event-codes.h
> > 22d6d060ac77 input: Add support for "Do Not Disturb"
> > 0c7dd00de018 input: Add event code for accessibility key
> > cfeb98b95fff Input: allocate keycode for Display refresh rate toggle
> >
> > 3 new ones since the beginning of the year.
> >
> >
> > > > TRIGGER_HAPPY range was added about 20 years
> > > > ago? For me, as a 27 year old it seems like a lifetime ago.
> >
> > 2010 so only 14 years ;)
> >
> > > >
> > > > 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.

What do you mean? If we go to separate event namespace then what KEY_MAX
would have to do with it?

> 
> 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),

No it ends at BTN_TRIGGER_HAPPY40. The rest are reserved and may be used
in the future for something else.

> 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?

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?

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.

> 
> 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.

Yes, but the growth is slower than 60+ keycodes at time, especially if
they to not carry any meaning but rather just placeholders.

Thanks.

-- 
Dmitry

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

[Peter Hutterer]

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

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

[Tomasz Pakuła]

On Wed, 7 Aug 2024 at 23:07, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> On Wed, Aug 07, 2024 at 10:22:13PM +0200, Tomasz Pakuła wrote:
> > On Wed, 7 Aug 2024 at 21:01, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > >
> > > On Wed, Aug 07, 2024 at 04:42:56PM +0800, Wei Shuai wrote:
> > > > yes, agree. either way, will be a revolution.
> > > >
> > > > At least, for me as X-Plane flight simulator gamer, a small change in
> > > > expanding the key max number can make my device work immediately
> > > >
> > > > Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> 于2024年8月7日周三 14:23写道：
> > > > >
> > > > > On Wed, 7 Aug 2024 at 07:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > > > > >
> > > > > > On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:
> > > > > > > > > > > 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.
> > > > > > >
> > > > > > > I do not think that frame notion is that important for keys. It is
> > > > > > > typically important for a pointing device state.
> > > > > >
> > > > > > true, I remember a conversation years back that frames aren't
> > > > > > consistently implemented in keyboard drivers anyway which is the reason
> > > > > > libinput sends (most) EV_KEY events immediately instad of waiting for a
> > > > > > SYN_REPORT.
> > > > > >
> > > > > > > > > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > > > > > > > > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > > > > > > > > using a custom Linux kernel with this patch on my Arch machine since about
> > > > > > > > > May, and didn't notice anything, even when compiling with debug flags and
> > > > > > > > > following and filtering dmesg.
> > > > > > > > >
> > > > > > > > > So here's the thing I'm most curious about. Is this something, you'd just
> > > > > > > > > want to resolve differently, to make it nicer and more logical, or is this
> > > > > > > > > really something that would break everything and doing it in this way will
> > > > > > > > > never be allowed/merged? That would make a lot of us sad :(
> > > > > > >
> > > > > > > We need to figure out not only how to handle your class of devices, but
> > > > > > > also allow extending number of keys that do have certain semantic
> > > > > > > meaning. Peter raised a lot of questions that we need to answer.
> > > > > > >
> > > > > > > But I wonder, these devices with large number of buttons that do not
> > > > > > > have predefined meaning - do they have to be a single input device? Can
> > > > > > > we create N input devices if we exceed the "trigger happy" range, all of
> > > > > > > them mapping to "trigger happy"? That would mean that userspace would
> > > > > > > keep track of key assignment on per-device basis.
> > > > > > >
> > > > > > > We already split HID devices on per-apllication (not userspace but HID
> > > > > > > application) basis, and also when there are several USB interfaces.
> > > > > >
> > > > > > Honestly, I'd vote against this.
> > > > > > re-combining input devices into a single device in userspace is a pain.
> > > > > > The split per application in HID is mostly fine because they're
> > > > > > usually physically different devices but I recently ran into the issue
> > > > > > with the uclogic drivers where various features are split across
> > > > > > event nodes. Thse devices have the ring on one event node, the buttons
> > > > > > on another, etc. Nothing in (my) userspace is currently set up for this
> > > > > > and it'd require a major rework in many places to be able to handle this
> > > > > > properly. And it requires that rework in every userspace stack, possibly
> > > > > > special-cased on a vendor id. In the end it was easier (re-)writing BPFs
> > > > > > to get the expected event node behaviour than dealing with the split.
> > > > > >
> > > > > > A device that arbitrarily splits makes this even more difficult - which
> > > > > > one of the event nodes has buttons 1-20 and which one has 21-40? We'd need
> > > > > > some other magic somewhere (e.g. hiding in uniq) and some digging around
> > > > > > in udev to figure out which ones are part of the same device.
> > > > > >
> > > > > > I'd rather not go with a simple-for-now solution that makes everything
> > > > > > in userspace more complicated, forever.
> > > > > >
> > > > > > Cheers,
> > > > > >   Peter
> > > > >
> > > > > Yes, I would also say splitting is, unfortunately, out of the question, because
> > > > > of the intended use-case of joysticks and other gaming devices. Most games do
> > > > > not handle multiple inputs and only allow for one device to be set up at the
> > > > > same time. This means, any buttons not present on the first device would simply
> > > > > be inaccessible and the end result would be the same as now.
> > >
> > > So how does this work with, for example, DualShock controllers. IIRC
> > > they are split into several sub-devices, such as game controller itself,
> > > accelerometer piece, and touchpad piece.
> >
> > Touchpad is easy as it's just a generic mouse. It just works as any other mouse.
> > Accelerometer can be dealt with Steam input/or maybe emulator that supports
> > gyro. But TBH, many games would just not support both gyro and buttons for
> > this reason. Fortunately, most games that actually need this gyro functionality
> > would be emulated as they're most likely Nintendo titles.
> >
> > >
> > > > >
> > > > > 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?
>
> 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?

> 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.

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".

> >
> > 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.
>
> Yes, but the growth is slower than 60+ keycodes at time, especially if
> they to not carry any meaning but rather just placeholders.
>
> Thanks.
>
> --
> Dmitry

I'm way over my head now.
Thanks for your patience

Tomasz

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

[Tomasz Pakuła]

On Thu, 8 Aug 2024 at 09:46, Tomasz Pakuła
<tomasz.pakula.oficjalny@gmail.com> wrote:
>
> On Wed, 7 Aug 2024 at 23:07, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > On Wed, Aug 07, 2024 at 10:22:13PM +0200, Tomasz Pakuła wrote:
> > > On Wed, 7 Aug 2024 at 21:01, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > >
> > > > On Wed, Aug 07, 2024 at 04:42:56PM +0800, Wei Shuai wrote:
> > > > > yes, agree. either way, will be a revolution.
> > > > >
> > > > > At least, for me as X-Plane flight simulator gamer, a small change in
> > > > > expanding the key max number can make my device work immediately
> > > > >
> > > > > Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> 于2024年8月7日周三 14:23写道：
> > > > > >
> > > > > > On Wed, 7 Aug 2024 at 07:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > > > > > >
> > > > > > > On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:
> > > > > > > > > > > > 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.
> > > > > > > >
> > > > > > > > I do not think that frame notion is that important for keys. It is
> > > > > > > > typically important for a pointing device state.
> > > > > > >
> > > > > > > true, I remember a conversation years back that frames aren't
> > > > > > > consistently implemented in keyboard drivers anyway which is the reason
> > > > > > > libinput sends (most) EV_KEY events immediately instad of waiting for a
> > > > > > > SYN_REPORT.
> > > > > > >
> > > > > > > > > > All in all, we've had people using this patch (but increasing KEY_MAX to a
> > > > > > > > > > whopping 0x4ff) for the past few years with no adverse effects. I've been
> > > > > > > > > > using a custom Linux kernel with this patch on my Arch machine since about
> > > > > > > > > > May, and didn't notice anything, even when compiling with debug flags and
> > > > > > > > > > following and filtering dmesg.
> > > > > > > > > >
> > > > > > > > > > So here's the thing I'm most curious about. Is this something, you'd just
> > > > > > > > > > want to resolve differently, to make it nicer and more logical, or is this
> > > > > > > > > > really something that would break everything and doing it in this way will
> > > > > > > > > > never be allowed/merged? That would make a lot of us sad :(
> > > > > > > >
> > > > > > > > We need to figure out not only how to handle your class of devices, but
> > > > > > > > also allow extending number of keys that do have certain semantic
> > > > > > > > meaning. Peter raised a lot of questions that we need to answer.
> > > > > > > >
> > > > > > > > But I wonder, these devices with large number of buttons that do not
> > > > > > > > have predefined meaning - do they have to be a single input device? Can
> > > > > > > > we create N input devices if we exceed the "trigger happy" range, all of
> > > > > > > > them mapping to "trigger happy"? That would mean that userspace would
> > > > > > > > keep track of key assignment on per-device basis.
> > > > > > > >
> > > > > > > > We already split HID devices on per-apllication (not userspace but HID
> > > > > > > > application) basis, and also when there are several USB interfaces.
> > > > > > >
> > > > > > > Honestly, I'd vote against this.
> > > > > > > re-combining input devices into a single device in userspace is a pain.
> > > > > > > The split per application in HID is mostly fine because they're
> > > > > > > usually physically different devices but I recently ran into the issue
> > > > > > > with the uclogic drivers where various features are split across
> > > > > > > event nodes. Thse devices have the ring on one event node, the buttons
> > > > > > > on another, etc. Nothing in (my) userspace is currently set up for this
> > > > > > > and it'd require a major rework in many places to be able to handle this
> > > > > > > properly. And it requires that rework in every userspace stack, possibly
> > > > > > > special-cased on a vendor id. In the end it was easier (re-)writing BPFs
> > > > > > > to get the expected event node behaviour than dealing with the split.
> > > > > > >
> > > > > > > A device that arbitrarily splits makes this even more difficult - which
> > > > > > > one of the event nodes has buttons 1-20 and which one has 21-40? We'd need
> > > > > > > some other magic somewhere (e.g. hiding in uniq) and some digging around
> > > > > > > in udev to figure out which ones are part of the same device.
> > > > > > >
> > > > > > > I'd rather not go with a simple-for-now solution that makes everything
> > > > > > > in userspace more complicated, forever.
> > > > > > >
> > > > > > > Cheers,
> > > > > > >   Peter
> > > > > >
> > > > > > Yes, I would also say splitting is, unfortunately, out of the question, because
> > > > > > of the intended use-case of joysticks and other gaming devices. Most games do
> > > > > > not handle multiple inputs and only allow for one device to be set up at the
> > > > > > same time. This means, any buttons not present on the first device would simply
> > > > > > be inaccessible and the end result would be the same as now.
> > > >
> > > > So how does this work with, for example, DualShock controllers. IIRC
> > > > they are split into several sub-devices, such as game controller itself,
> > > > accelerometer piece, and touchpad piece.
> > >
> > > Touchpad is easy as it's just a generic mouse. It just works as any other mouse.
> > > Accelerometer can be dealt with Steam input/or maybe emulator that supports
> > > gyro. But TBH, many games would just not support both gyro and buttons for
> > > this reason. Fortunately, most games that actually need this gyro functionality
> > > would be emulated as they're most likely Nintendo titles.
> > >
> > > >
> > > > > >
> > > > > > 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?
> >
> > 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?
>
> > 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.
>
> 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".
>
> > >
> > > 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.
> >
> > Yes, but the growth is slower than 60+ keycodes at time, especially if
> > they to not carry any meaning but rather just placeholders.
> >
> > Thanks.
> >
> > --
> > Dmitry
>
> I'm way over my head now.
> Thanks for your patience
>
> Tomasz

I dug around the kernel some more, and have few ideas and questions I would like
to pose, before I send out another patch and make a fool of myself.

1. For the compatible solution, and I know this might sound
sacreligious, but would it
be at all considered ok, if joysticks could use the KEY_MACRO range?
Current behavior
in hid-input.c is to just add (BTN_TRIGGER_HAPPY - 0x10) after 16 buttons.
KEY_MACRO range lies directly beneath TRIGGER_HAPPY so we would only replace
BTN_TRIGGER_HAPPY with KEY_MACRO1. I know this is not their intended use, but
their description says "Some keyboards have keys which do not have a
defined meaning,
these keys are intended to be programmed / bound to macros by the user"

Binding buttons to do some actions sounds just like a dame controller,
in a way :P
I already tested this change and it enabled over 40 additional buttons
without the need
to intervene in software. This was picked up by SDL, proton, firefox
and basically
everything, as these usages are obviously not crossing KEY_MAX.

To squeeze just a little bit more, we could utilize the BTN_0 to BTN_9
range. I couldn't
find their meaning, but I suppose the definition of a joystick/gamepad
could be stretched
to include these.

2. For the better, more scalable solution, your proposition from the
start is the best one.
I thought that overflowing buttons could be just hardcoded to one
selected usage in
hid-input.c. Be it BTN_MISC, BTN_JOYSTICK. Deduplication would make sure, they
don't actually send any bogus EV_KEY events.

Let's take a look at usage setup in hid-input.c
We can see that if a usage is from EV_KEY range, EV_MSC usage is always appended
and it will send not only EV_KEY events, but EV_MSC MSC_SCAN events as well.

if (usage->type == EV_KEY) {
    set_bit(EV_MSC, input->evbit);
    set_bit(MSC_SCAN, input->mscbit);
}

This sadly comes AFTER deduplication. It would probably be better to
set it explicitly in the
joystick/gamepad switch entry. MSC_SCAN already has a value that seems
to depend on the
button number, but a dedicated MSC_PROG_KEY would indeed be better
suited for this, along
with MSC_PROG_VAL, as you said, as MSC_SCAN and MSC_PROG_KEY would not contain
it. Or maybe we could do some bit magic and send the state with the
value. MSG could indicate
state. This is a bit less self explanatory but we only need to handle one event.

Now, software such as SDL could be changed so it doesn't care about
usages at all, and
gets the button number from these two. A legacy path could be retained
as detection could be
based on the existence of these MSC_PROG_* events.

Cheers
Tomasz

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

[Peter Hutterer]

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

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

[Peter Hutterer]

This one apparently slipped through,

On Thu, Aug 08, 2024 at 06:42:37PM +0200, Tomasz Pakuła wrote:
[...]
> I dug around the kernel some more, and have few ideas and questions I would like
> to pose, before I send out another patch and make a fool of myself.
> 
> 1. For the compatible solution, and I know this might sound
> sacreligious, but would it be at all considered ok, if joysticks could
> use the KEY_MACRO range?  Current behavior in hid-input.c is to just
> add (BTN_TRIGGER_HAPPY - 0x10) after 16 buttons.  KEY_MACRO range lies
> directly beneath TRIGGER_HAPPY so we would only replace
> BTN_TRIGGER_HAPPY with KEY_MACRO1. I know this is not their intended
> use, but their description says "Some keyboards have keys which do not
> have a defined meaning, these keys are intended to be programmed /
> bound to macros by the user"

iirc the hid-input.c behaviour is fallthrough behaviour rather than "we
explicitly map it to this", right?

Either way, the KEY_MACRO range has an explicit meaning and if you start
re-using this for something else it's the same problem as mentioned
elsewhere - you now expect all of userspace to encode those special
exceptions forever just to make the kernel patches a bit easier. That's
... not ideal ;)

> Binding buttons to do some actions sounds just like a dame controller,
> in a way :P I already tested this change and it enabled over 40
> additional buttons without the need to intervene in software. This was
> picked up by SDL, proton, firefox and basically
> everything, as these usages are obviously not crossing KEY_MAX.
> 
> To squeeze just a little bit more, we could utilize the BTN_0 to BTN_9
> range. I couldn't find their meaning, but I suppose the definition of
> a joystick/gamepad could be stretched to include these.

They're used by e.g. wacom tablets for the physical tablet buttons (not
those on the stylus but on the actual tablet). And their meaning is
basically "numbered buttons without an explicit meaning". Using those
will likely get your device tagged as tablet though, you'd need to
double-check what udev's builtin-input_id does to make sure otherwise
we'll have to quirk every device one-by-one.

Cheers,
  Peter
 
> 2. For the better, more scalable solution, your proposition from the
> start is the best one.
> I thought that overflowing buttons could be just hardcoded to one
> selected usage in
> hid-input.c. Be it BTN_MISC, BTN_JOYSTICK. Deduplication would make sure, they
> don't actually send any bogus EV_KEY events.
> 
> Let's take a look at usage setup in hid-input.c
> We can see that if a usage is from EV_KEY range, EV_MSC usage is always appended
> and it will send not only EV_KEY events, but EV_MSC MSC_SCAN events as well.
> 
> if (usage->type == EV_KEY) {
>     set_bit(EV_MSC, input->evbit);
>     set_bit(MSC_SCAN, input->mscbit);
> }
> 
> This sadly comes AFTER deduplication. It would probably be better to
> set it explicitly in the
> joystick/gamepad switch entry. MSC_SCAN already has a value that seems
> to depend on the
> button number, but a dedicated MSC_PROG_KEY would indeed be better
> suited for this, along
> with MSC_PROG_VAL, as you said, as MSC_SCAN and MSC_PROG_KEY would not contain
> it. Or maybe we could do some bit magic and send the state with the
> value. MSG could indicate
> state. This is a bit less self explanatory but we only need to handle one event.
> 
> Now, software such as SDL could be changed so it doesn't care about
> usages at all, and
> gets the button number from these two. A legacy path could be retained
> as detection could be
> based on the existence of these MSC_PROG_* events.
> 
> Cheers
> Tomasz