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 20 May 2010 18:20 On Thu, May 20, 2010 at 12:08 AM, Henrik Rydberg <rydberg(a)euromail.se> wrote: > Hi Ping, > > first out, thank you for your detailed analysis, it aids in removing ambiguities > �and defining the borders of the protocol. Glad to hear from you directly this time :). I have more questions. > It helps to think of both TRACKING_ID and BLOB_ID as labels of a single > identified contact which occupies one slot. I need double check with you although I think I know the answer. From your explanation and examples so far, I see MT_SLOT is only associated with one (x,y). Is this true? If yes, can we eliminate the requirement for TRACKING_ID? If you think the requirement is necessary, can you give me an example where missing the TRACKING_ID would bring issue or confusion? >To represent a set of contacts as an > entity, one needs to add a label to the slot, representing that entity. Doesn't MT_SLOT itself serves as a label? It has a value. May be ABS_MT_SLOT_ID fits the term more closely. > As pointed out in a later reply by Peter, the BLOB_ID serves this purpose well. The > name is slightly unfortunate, being a bit too generic. Let us use this > discussion to pin down a more exact definition: > > ABS_MT_BLOB_ID is a label which groups contacts in close relation to each other, > such as a hand. I think I get this part. However, (too late to regret that you've replied to me :) > With this in mind, the sequence becomes > > SYN_MT_SLOT 0 > ABS_MT_BLOB_ID 11 > ABS_MT_TRACKING_ID 45 > ABS_MT_POSITION_X x[0] > ABS_MT_POSITION_Y y[0] > SYN_MT_SLOT 1 > ABS_MT_BLOB_ID 11 > ABS_MT_TRACKING_ID 46 > ABS_MT_POSITION_X x[1] > ABS_MT_POSITION_Y y[1] > SYN_MT_SLOT 2 > ABS_MT_BLOB_ID 11 > ABS_MT_TRACKING_ID 47 > ABS_MT_POSITION_X x[2] > ABS_MT_POSITION_Y y[2] > SYN_MT_SLOT 3 > ABS_MT_BLOB_ID 89 > ABS_MT_TRACKING_ID 30 > ABS_MT_POSITION_X x[3] > ABS_MT_POSITION_Y y[3] > SYN_REPORT I would think something like the following would make sense too: ABS_MT_BLOB_ID 11 ABS_MT_TRACKING_ID 45 ABS_MT_SLOT_ID 0 ABS_MT_POSITION_X x[0] ABS_MT_POSITION_Y y[0] ABS_MT_SLOT_ID 1 ABS_MT_POSITION_X x[1] ABS_MT_POSITION_Y y[1] ABS_MT_SLOT_ID 2 ABS_MT_POSITION_X x[2] ABS_MT_POSITION_Y y[2] SYN_MT_BLOB ABS_MT_BLOB_ID 89 ABS_MT_SLOT_ID 3 ABS_MT_TRACKING_ID 30 ABS_MT_POSITION_X x[3] ABS_MT_POSITION_Y y[3] SYN_MT_BLOB SYN_REPORT where we have two blob of data. They represent finger 1 and finger 2. Finger 1 has a tracking number 11 while finger 2 has 30. We do not track the three contacts inside the blob since they all belong to the same finger. We could even combine type A and B as: ABS_MT_TRACKING_ID 0 # indicates first finger or hand ABS_MT_BLOB 3 # indicates 3 contacts in the blob ABS_MT_POSITION_X x[0] ABS_MT_POSITION_Y y[0] SYN_MT_REPORT ABS_MT_POSITION_X x[1] ABS_MT_POSITION_Y y[1] SYN_MT_REPORT ABS_MT_POSITION_X x[2] ABS_MT_POSITION_Y y[2] SYN_MT_REPORT ABS_MT_TRACKING_ID 1 # indicates second finger or hand ABS_MT_BLOB_ID 1 # indicates 1 contact in the blob ABS_MT_POSITION_X x[3] ABS_MT_POSITION_Y y[3] SYN_REPORT where SYN_MT_BLOB is unnecessary since we know how many contacts we are going to get. I would expect this approach complicates the implementation in the kernel. So I am not sure if it makes sense to use it or not. Just to share some random thoughts with you. 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: Henrik Rydberg on 20 May 2010 18:50 Ping Cheng wrote: > On Thu, May 20, 2010 at 12:08 AM, Henrik Rydberg <rydberg(a)euromail.se> wrote: >> Hi Ping, >> >> first out, thank you for your detailed analysis, it aids in removing ambiguities >> and defining the borders of the protocol. > > Glad to hear from you directly this time :). I have more questions. > >> It helps to think of both TRACKING_ID and BLOB_ID as labels of a single >> identified contact which occupies one slot. > > I need double check with you although I think I know the answer. From > your explanation and examples so far, I see MT_SLOT is only associated > with one (x,y). Is this true? If yes, can we eliminate the > requirement for TRACKING_ID? If you think the requirement is > necessary, can you give me an example where missing the TRACKING_ID > would bring issue or confusion? Yes, each slot can only be associated with one (x, y) pair. No, we cannot disregard the tracking id. A slot tracks a single contact for its entire lifetime, during which the tracking id serves no purpose, but the slot cannot tell us when the contact is replaced by a new one. This information is carried by the tracking id. > >> To represent a set of contacts as an >> entity, one needs to add a label to the slot, representing that entity. > > Doesn't MT_SLOT itself serves as a label? It has a value. May be > ABS_MT_SLOT_ID fits the term more closely. The slot id tells which slot is currently being modified, and carries no information about the slot itself. To represent a relation between different contacts, a value representing that relation needs to be added to the event stream, there is no doubt about that. The BLOB_ID is such a label, and there will likely be others in the future as well. > >> As pointed out in a later reply by Peter, the BLOB_ID serves this purpose well. The >> name is slightly unfortunate, being a bit too generic. Let us use this >> discussion to pin down a more exact definition: >> >> ABS_MT_BLOB_ID is a label which groups contacts in close relation to each other, >> such as a hand. > > I think I get this part. However, (too late to regret that you've > replied to me :) > >> With this in mind, the sequence becomes >> >> SYN_MT_SLOT 0 >> ABS_MT_BLOB_ID 11 >> ABS_MT_TRACKING_ID 45 >> ABS_MT_POSITION_X x[0] >> ABS_MT_POSITION_Y y[0] >> SYN_MT_SLOT 1 >> ABS_MT_BLOB_ID 11 >> ABS_MT_TRACKING_ID 46 >> ABS_MT_POSITION_X x[1] >> ABS_MT_POSITION_Y y[1] >> SYN_MT_SLOT 2 >> ABS_MT_BLOB_ID 11 >> ABS_MT_TRACKING_ID 47 >> ABS_MT_POSITION_X x[2] >> ABS_MT_POSITION_Y y[2] >> SYN_MT_SLOT 3 >> ABS_MT_BLOB_ID 89 >> ABS_MT_TRACKING_ID 30 >> ABS_MT_POSITION_X x[3] >> ABS_MT_POSITION_Y y[3] >> SYN_REPORT > > I would think something like the following would make sense too: > > ABS_MT_BLOB_ID 11 > ABS_MT_TRACKING_ID 45 > ABS_MT_SLOT_ID 0 > ABS_MT_POSITION_X x[0] > ABS_MT_POSITION_Y y[0] > ABS_MT_SLOT_ID 1 > ABS_MT_POSITION_X x[1] > ABS_MT_POSITION_Y y[1] > ABS_MT_SLOT_ID 2 > ABS_MT_POSITION_X x[2] > ABS_MT_POSITION_Y y[2] > SYN_MT_BLOB > ABS_MT_BLOB_ID 89 > ABS_MT_SLOT_ID 3 > ABS_MT_TRACKING_ID 30 > ABS_MT_POSITION_X x[3] > ABS_MT_POSITION_Y y[3] > SYN_MT_BLOB > SYN_REPORT > > where we have two blob of data. They represent finger 1 and finger 2. > Finger 1 has a tracking number 11 while finger 2 has 30. We do not > track the three contacts inside the blob since they all belong to the > same finger. We could even combine type A and B as: Well, the way the protocol is defined, SYN_MT_BLOB does not exist, and any attribute change outside the slot id context simply has no meaning. > > ABS_MT_TRACKING_ID 0 # indicates first finger or hand > ABS_MT_BLOB 3 # indicates 3 contacts in the blob > ABS_MT_POSITION_X x[0] > ABS_MT_POSITION_Y y[0] > SYN_MT_REPORT > ABS_MT_POSITION_X x[1] > ABS_MT_POSITION_Y y[1] > SYN_MT_REPORT > ABS_MT_POSITION_X x[2] > ABS_MT_POSITION_Y y[2] > SYN_MT_REPORT > ABS_MT_TRACKING_ID 1 # indicates second finger or hand > ABS_MT_BLOB_ID 1 # indicates 1 contact in the blob > ABS_MT_POSITION_X x[3] > ABS_MT_POSITION_Y y[3] > SYN_REPORT > > where SYN_MT_BLOB is unnecessary since we know how many contacts we > are going to get. I would expect this approach complicates the > implementation in the kernel. So I am not sure if it makes sense to > use it or not. Just to share some random thoughts with you. Thank you for your random suggestions. 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: Ping Cheng on 20 May 2010 23:40 On Thu, May 20, 2010 at 3:48 PM, Henrik Rydberg <rydberg(a)euromail.se> wrote: >> I need double check with you although I think I know the answer. From >> your explanation and examples so far, I see MT_SLOT is only associated >> with one (x,y). Is this true? �If yes, can we eliminate the >> requirement for TRACKING_ID? If you think the requirement is >> necessary, can you give me an example where missing the TRACKING_ID >> would bring issue or confusion? > > Yes, each slot can only be associated with one (x, y) pair. No, we cannot > disregard the tracking id. A slot tracks a single contact for its entire > lifetime, during which the tracking id serves no purpose, but the slot cannot > tell us when the contact is replaced by a new one. This information is carried > by the tracking id. Ok, I've made enough noise in this thread. If we change SYN_MT_SLOT to ABS_MT_SLOT_ID (or something starting with ABS_ of your choice), I have no more questions. You can put my reviewed-by in the patch if that counts for anything: Reviewed-by: Ping Cheng <pingc(a)wacom.com> 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 21 May 2010 11:50 On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi(a)seas.upenn.edu> wrote: >> ABS_MT_BLOB_ID 11 >> ABS_MT_TRACKING_ID 45 >> ABS_MT_SLOT_ID 0 >> ABS_MT_POSITION_X x[0] >> ABS_MT_POSITION_Y y[0] >> ABS_MT_SLOT_ID 1 >> ABS_MT_POSITION_X x[1] >> ABS_MT_POSITION_Y y[1] >> ABS_MT_SLOT_ID 2 >> ABS_MT_POSITION_X x[2] >> ABS_MT_POSITION_Y y[2] >> SYN_MT_BLOB >> ABS_MT_BLOB_ID 89 >> ABS_MT_SLOT_ID 3 >> ABS_MT_TRACKING_ID 30 >> ABS_MT_POSITION_X x[3] >> ABS_MT_POSITION_Y y[3] >> SYN_MT_BLOB >> SYN_REPORT >> >> where we have two blob of data. They represent finger 1 and finger 2. >> Finger 1 has a tracking number 11 while finger 2 has 30.� We do not >> track the three contacts inside the blob since they all belong to the >> same finger.� We could even combine type A and B as: > > ??? > > 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. 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: Henrik Rydberg on 21 May 2010 17:30
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. 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/ |