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

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 [off-list ref] 于2024年8月7日周三 14:23写道：

On Wed, 7 Aug 2024 at 07:17, Peter Hutterer [off-list ref] wrote:

quoted

On Tue, Aug 06, 2024 at 09:12:24PM -0700, Dmitry Torokhov wrote:

quoted

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

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