Messages in this thread | | | From | "Henrik Rydberg" <> | Date | Mon, 6 Feb 2012 10:00:28 +0100 | Subject | Re: [PATCH v4] Input: Add EVIOC mechanism for MT slots |
| |
Hi Daniel,
> Instead of returning the values of just one event type, can you please > return values for all defined MT event types for all slots? Userspace > can already know how big such an array would be required, since it can > probe to determine how many ABS_MT types have been defined.
Userland does not always want all MT values, it depends on which are in actual use. Having an ioctl that returns the values for a single event code therefore makes sense. We also have to care about the restrictions of the ioctl interface: Even with the present patch, we are limited to 4000 slots, since we can only specify a buffer size of 16 kilobytes.
> It seems like the most common use case for this API is to fetch the > complete "initial state" when a userspace program first attaches to a > (stateful) evdev device. Fetching all at once would be slightly more > efficient, and would resolve (or at worst minimize) race conditions > that could occur if input events are arriving while userspace is still > slowly ioctl'ing out the event type initial states, one at a time.
The same argument applies to _all_ input events, but in practise, only a few less frequent events really need to be looked up. I agree that a one-call-captures-all function would not hurt in some situations, but I do not think it is justified in this case.
The race condition is present regardless of the method used. Looking at input events as a whole, a method to capture the state in conjunction with opening the device would be good, but that problem is of quite a different scope.
> If there are strong use cases for 'just probe one event type', perhaps > you can keep the proposed API, but allow a special event type value, > like "ABS_MT_*", to fetch all?
I really think "all" is less useful; a bitmask of wanted values would make more sense. You are welcome to supply such a patch. ;-)
> BTW, I am very happy that you are finally plugging this particular > issue since it has been bugging me for many months. We sometimes use > a userspace tools to record evdev events for a touch device while a > user is performing a multitouch gesture. If the userspace tool starts > while there are already contacts on the device, there is currently no > unambiguous way to determine what that initial state should have been. > Thus, some information is always lost. This patch would allow us to > address this in the tools. I've just been to busy/lazy to propose a > fix of my own :).
Yep, this goes for all of us. :-)
Cheers, Henrik
| |