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