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