input: mt: Document the MT event slot protocol (rev2)
in [Kernel]
|
Prev: [GIT PULL v2 0/5] perf tools fixes and improvements
Next: [RESEND -v2][PATCH 3/3] mem-hotplug: fix potential race while building zonelist for new populated zone
From: Ping Cheng on 21 May 2010 23:20 On Fri, May 21, 2010 at 2:25 PM, Henrik Rydberg <rydberg(a)euromail.se> wrote: > Ping Cheng wrote: >> On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi(a)seas.upenn.edu> wrote: > [...] >>> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions? >> >> You are definitely on the right track. �The fingers/touch objects can >> be represented two-dimensionally (x,y) instead of one-dimensionally >> (ABS_MT_TRACKING_ID). �I think we can survive with the current MT_BLOB >> definition although some optimization would be helpful, especially for >> filtering. For the sake of Henrik great effort, I'd like to see his >> current patchset gets in the tree before we start another round of >> "suggestions". >> >> Thank you for asking. > > Regarding blobs, I confused myself yesterday. The original intention of the blob > �id was in fact to be able to "paint" more generic contact forms. However, no > driver has come close to doing this yet, so it has gotten close to no attention. > Now, to address the question of how to communicate more elaborate contact forms, > it seems one can combine the two goals "one position per slot" and "multiple > positions per contact" by simply repeating the same tracking id for a set of > slots, like this: > > ABS_SLOT 0 > ABS_MT_TRACKING_ID 14 > ABS_MT_POSITION_X x[0] > ABS_MT_POSITION_Y y[0] > ABS_SLOT 1 > ABS_MT_TRACKING_ID 14 > ABS_MT_POSITION_X x[1] > ABS_MT_POSITION_Y y[1] > ABS_SLOT 2 > ABS_MT_TRACKING_ID 14 > ABS_MT_POSITION_X x[2] > ABS_MT_POSITION_Y y[2] This solution matches with my imagination more closely. Let's stay with it for now. I may come up with other suggestions once I have time to do real testing with the protocol. Thank you, Henrik, for your continuous effort. Ping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Hutterer on 24 May 2010 01:10 On Thu, May 20, 2010 at 12:40:08PM +0200, Henrik Rydberg wrote: > Peter Hutterer wrote: > [...] > >>> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know > >>> in advance if a device may use slots or not? > >> Eventually, this might become true, but you are pointing at one of the weaker > >> points of the current setup. There is no bit field for the EV_SYN events, so > >> there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This > >> could quite possibly be added to the EVIO interface. Meanwhile, the method I use > >> is to detect the first SYN_MT_SLOT and select parser based on that information. > > > > I'd really prefer if there was some way to detect this. While I'm not quite > > sure how the matching X drivers would look like it's likely that the setups > > will be different for drivers that support slots and those that don't. > > e.g. those that don't have slots simply send events as valuators, those that > > do may split into multiple devices. > > > > Doing this at runtime - after the device has been set up is...tricky. > > Changing SYN_MT_SLOT to ABS_MT_SLOT will take care of this. > > >> If you are thinking of a setup where one program is already hooked up to the > >> device, and a new one comes in just as the message in question appears on the > >> wire, it just means the new program will have to spend some time catching up. If > >> this should ever become a problem, one could possibly add a send-full-state > >> method to the input layer, to be issued when the new program opens the device. I > >> doubt this will be needed in practice though, since contacts change all the time. > > > > This was the case I was wondering about. While I agree with the last part > > (contacts change all the time) the side-effect that you'll get from this is > > that devices can seemingly be non-responsive for random periods of time. > > > > If you have a finger down when the X server starts or after a VT switch (or > > even a fast user switch), the driver will have to drop events. So you can > > wriggle your finger around and nothing happens, but once you lift it goes > > "well, now it works again". Since this happens only once in a while, it can > > make the whole lot appear flaky. Especially if one finger works and the > > other one doesn't. > > > > So I guess it comes down to whether sending SYN_MT_SLOT with every event > > costs too much compared to these admittedly rare use-cases. They're not much > > different to the current button events either, if you weren't there when a > > button was pressed you won't know. So I'm somewhat indifferent about this > > bit. > > Yes, it is a inherent property of the input protocol between the kernel and user > space. A different problem, in other words. > > > And yes, you could add it once we find it's an issue, but by then someone > > has already spent time to work around this. And when you then start sending > > slot events all the time, you admit that writing the workaround was just a > > time waster :) > > Work around what, exactly? I was referring to having a protocol where processes has to ignore contacts already down until they've been there when a contact was pressed (and your comment that if this becomes an issue it could be added lateron). Now, the ignoring part needs to be written (this is the "workaround" referred to above). if you're planning to add it later, we need to cater for that part as well then, having two implementations depending on the kernel versions. but this is just for clarification, it's a moot point anyway given that button events have the same behaviour. so, nevermind, I think we can just ignore it and get on with life. Cheers, Peter > >> As a side note, the notion of a used slot depends on how the attributes of the > >> slot are interpreted. The method described in the document treats an > >> ABS_MT_TRACKING_ID value outside of the driver-specified value range as an > >> unused slot. > > > > It's easier for a latecomer to guess a tracking ID since you can just > > assign any random value to it, provided the kernel guarantees to only send > > updates on the tracking ID for changes. This doesn't quite work for slots. > > > > But I'm not sure what your last sentence means. Does this mean the kernel > > will open a new slot for out-of-range tracking IDs? I'm missing something > > here. > > I am referring to the notion of create-move-destroy from earlier discussions, > and the question of how it is implemented using slots. The document is a bit > unclear on this point, so I will add a note stating something like this: > > * Every slot with a tracking id within the value range represents a contact. > > * Tracking ids not previously present are considered new. > > * Tracking ids no longer present are considered removed. > > Cheers, > Henrik > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Hutterer on 24 May 2010 01:30 On Fri, May 21, 2010 at 11:25:41PM +0200, Henrik Rydberg wrote: > Ping Cheng wrote: > > On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi(a)seas.upenn.edu> wrote: > [...] > >> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions? > > > > You are definitely on the right track. The fingers/touch objects can > > be represented two-dimensionally (x,y) instead of one-dimensionally > > (ABS_MT_TRACKING_ID). I think we can survive with the current MT_BLOB > > definition although some optimization would be helpful, especially for > > filtering. For the sake of Henrik great effort, I'd like to see his > > current patchset gets in the tree before we start another round of > > "suggestions". > > > > Thank you for asking. > > Regarding blobs, I confused myself yesterday. The original intention of the blob > id was in fact to be able to "paint" more generic contact forms. However, no > driver has come close to doing this yet, so it has gotten close to no attention. > Now, to address the question of how to communicate more elaborate contact forms, > it seems one can combine the two goals "one position per slot" and "multiple > positions per contact" by simply repeating the same tracking id for a set of > slots, like this: > > ABS_SLOT 0 > ABS_MT_TRACKING_ID 14 > ABS_MT_POSITION_X x[0] > ABS_MT_POSITION_Y y[0] > ABS_SLOT 1 > ABS_MT_TRACKING_ID 14 > ABS_MT_POSITION_X x[1] > ABS_MT_POSITION_Y y[1] > ABS_SLOT 2 > ABS_MT_TRACKING_ID 14 > ABS_MT_POSITION_X x[2] > ABS_MT_POSITION_Y y[2] > > Not all too different from what you suggested, and there is no blob id involved > at all. And yes, it would require additional parsing power at the user end. > Something for later. This is confusing me now :) How would a device get multiple x/y coordinates for a single contact? I could understand a range of coordinates but that's what we have the ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y coordinates, wouldn't that be two touchpoints, tracked individually and thus with a different tracking ID? I read the example above as _the_ example for using blob IDs to combine multiple contacts into one semantic contact. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ping Cheng on 24 May 2010 01:50 On Sun, May 23, 2010 at 10:25 PM, Peter Hutterer <peter.hutterer(a)who-t.net> wrote: > On Fri, May 21, 2010 at 11:25:41PM +0200, Henrik Rydberg wrote: >> Ping Cheng wrote: >> > On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi(a)seas.upenn.edu> wrote: >> [...] >> >> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions? >> > >> > You are definitely on the right track. �The fingers/touch objects can >> > be represented two-dimensionally (x,y) instead of one-dimensionally >> > (ABS_MT_TRACKING_ID). �I think we can survive with the current MT_BLOB >> > definition although some optimization would be helpful, especially for >> > filtering. For the sake of Henrik great effort, I'd like to see his >> > current patchset gets in the tree before we start another round of >> > "suggestions". >> > >> > Thank you for asking. >> >> Regarding blobs, I confused myself yesterday. The original intention of the blob >> �id was in fact to be able to "paint" more generic contact forms. However, no >> driver has come close to doing this yet, so it has gotten close to no attention. >> Now, to address the question of how to communicate more elaborate contact forms, >> it seems one can combine the two goals "one position per slot" and "multiple >> positions per contact" by simply repeating the same tracking id for a set of >> slots, like this: >> >> ABS_SLOT 0 >> ABS_MT_TRACKING_ID 14 >> ABS_MT_POSITION_X x[0] >> ABS_MT_POSITION_Y y[0] >> ABS_SLOT 1 >> ABS_MT_TRACKING_ID 14 >> ABS_MT_POSITION_X x[1] >> ABS_MT_POSITION_Y y[1] >> ABS_SLOT 2 >> ABS_MT_TRACKING_ID 14 >> ABS_MT_POSITION_X x[2] >> ABS_MT_POSITION_Y y[2] >> >> Not all too different from what you suggested, and there is no blob id involved >> at all. And yes, it would require additional parsing power at the user end. >> Something for later. > > This is confusing me now :) > > How would a device get multiple x/y coordinates for a single contact? I > could understand a range of coordinates but that's what we have the > ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y > coordinates, wouldn't that be two touchpoints, tracked individually and thus > with a different tracking ID? > > I read the example above as _the_ example for using blob IDs to combine > multiple contacts into one semantic contact. As Henrik pointed out, the current BLOB format is for "more generic contact forms", such as rectangles or ellipses. They are special blobs. A generic (true) blob doesn't have to have a regular shape. It is most likely in an irregular shape. They would be represented in an array of points/contacts/(x,y)s, whichever term works for you :). tbh, I don't know what exact format we are going to use. But, I feel we can live with Henrik's current format, at least for a while. Ping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ping Cheng on 24 May 2010 02:10
On Sun, May 23, 2010 at 9:58 PM, Peter Hutterer <peter.hutterer(a)who-t.net> wrote: >> > And yes, you could add it once we find it's an issue, but by then someone >> > has already spent time to work around this. And when you then start sending >> > slot events all the time, you admit that writing the workaround was just a >> > time waster :) >> >> Work around what, exactly? > > I was referring to having a protocol where processes has to ignore contacts > already down until they've been there when a contact was pressed (and your > comment that if this becomes an issue it could be added lateron). > Now, the ignoring part needs to be written (this is the "workaround" > referred to above). if you're planning to add it later, we need to cater for > that part as well then, having two implementations depending on the kernel > versions. > > but this is just for clarification, it's a moot point anyway given that > button events have the same behaviour. This topic is outside of the _MT_ protocol discussion. However, it is indeed an issue with all filtered input events, both for MT and regular ones. I think we need to add an ioctl to enable user land driver/client to signal the kernel driver to send all events without filtering, just once. Hot-plugged devices and X driver starts after user has contacted with the device are two examples that the client would miss filtered events. Dmitry, do you think it is a valid suggestion? I've had this issue for ages (but never had time to work on it :(. Ping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |