On Wed, May 19, 2010 at 6:03 PM, Rafi Rubin <rafi@xxxxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/19/10 20:51, Ping Cheng wrote: >> On Wed, May 19, 2010 at 5:26 PM, Rafi Rubin <rafi@xxxxxxxxxxxxxx> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 05/19/10 20:13, Ping Cheng wrote: >>>> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@xxxxxxxxxxxxxx> wrote: >>>>> My understanding is that it would be more like >>>>> + SYN_MT_SLOT 0 >>>>> + ABS_MT_POSITION_X x >>>>> + ABS_MT_POSITION_Y y >>>>> + SYN_REPORT >>>>> + SYN_MT_SLOT 0 >>>>> + ABS_MT_POSITION_X x >>>>> + ABS_MT_POSITION_Y y >>>>> + SYN_REPORT >>>>> + SYN_MT_SLOT 0 >>>>> + ABS_MT_POSITION_X x >>>>> + ABS_MT_POSITION_Y y >>>>> + SYN_MT_SLOT 1 >>>>> + ABS_MT_POSITION_X x >>>>> + ABS_MT_POSITION_Y y >>>>> + SYN_REPORT >>>> >>>> You are right if one slot only has or is only allowed to have one >>>> point. My scenario is that one slot can have more than one point. >>>> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID >>>> in such a way that it avoids as much overlap as possible. >>>> >>>> And hopefully it makes sesne in the reality too. >>> >>> Please clarify by what you mean by more than one point. >> >> I might have been confused myself by ABS_MT_BLOB_ID and SYN_MT_SLOT >> here. What I meant by "more than one point" is a contact (or touch, I >> am not sure which one is the right term :) is represented by a few >> (x,y) coordinates. Maybe we should use SYN_MT_SLOT for my case? The last sentence above should be "Maybe we should NOT use SYN_MT_SLOT for my case?" or "Maybe I should use MT_BLOB_ID for that case?". A typical typo for those whose hands are slower than their brains :). >>> I may be misunderstanding, but I thought that these slots are basically a >>> superior replacement to tracking id. >>> >>> one finger -> one slot >> >> This is what I needed to understand. Is slot for one (x,y) only or can >> it also be used for more than one set of (x,y)? >> >>> But with slots we can use the filtering that input provides, which we've been >>> by-passing with the existing MT protocol (at least that's what I think Henrik's >>> goal is). >> >> Good to know that filtering has already been considered. I know I must >> be out of sync with Henrik's goal. That's why I wanted to show my >> ignorance :). >> >> Ping >> > > Hey, sometimes Mark Twain's old advice is good, and sometimes its not. > > It's better to keep your mouth shut and be thought a fool than to open it and > leave no doubt. --Mark Twain > > > I think this is definitely a case where he's wrong. We need to sync up so that > we're all implementing the same protocol, and can move on to the next > interesting problem. I hope this is the common goal for everyone who has been involved in the _MT_ support. Ping -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
