On Thu, 8 Aug 2024 at 09:46, Tomasz Pakuła
<tomasz.pakula.oficjalny@xxxxxxxxx> wrote:
>
> On Wed, 7 Aug 2024 at 23:07, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 于2024年8月7日周三 14:23写道：
> > > > > >
> > > > > > On Wed, 7 Aug 2024 at 07:17, Peter Hutterer <peter.hutterer@xxxxxxxxx> 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
