On Mon, Mar 22, 2010 at 4:57 PM, Henrik Rydberg <[email protected]> wrote: > Ping Cheng wrote: >> 2010/3/20 Ping Cheng <[email protected]>: >>> I might have mistaken the definition of tracking ID here. >> >> After reading the Multi-touch (MT) Protocol again, I think combining >> ABS_MT_TRACKING_ID with ABS_MT_BLOB_ID resolves my ID issue. So, I >> withdraw my support to add a software tracking ID in the kernel. I >> think ABS_MT_BLOB_ID serves as the software tracking ID, if I don't >> misunderstand the use of ABS_MT_BLOB_ID here. > > There are no drivers using the blob id currently, and it has a completely > different purpose.
Thank you Henrik. It really helps. Can you explain a bit more of the purpose of ABS_MT_BLOB_ID? > The ABS_MT_TRACKING_ID is the only event that has to do with > finger tracking. By software tracking is meant code that computes that event, > such that it can be included in drivers that does not support it in hardware. I see. How are we going to report the computed events to the user land? >> But, I reserve the request for a contact count in the kernel until I >> understand the definition of "the whole group". >> Henrik, by "the whole group", do you mean: >> >> 1. all the contacts/fingers on the screen/surface at a certain time, or >> 2. all the touch points supported by the hardware, or >> 3. all the contacts defined in a blob? > > The first option, all present contacts. > >> If it is case 1, it would be nice if we (X driver or contact driver in >> your term :) know the total contacts the hardware support (if there is >> a limit) and how many contacts we are getting; > > The protocol defines a generic way of sending a variable amount of contacts. > The > contact count is obtained by counting the number of non-empty finger packets > between SYN_REPORT events. To add a second way to obtain the same number would > be redundant. > > Regarding total contacts supported by the hardware, the protocol currently > deals > with single-user finger contacts. The natural limitation is ten. :-) Yes, > there > could be additional tools like pens available, and yes, maybe some devices > support multiple users as well, but generally, it is more a question of how > many > contacts one wants to support in the X driver. One should be prepared to drop > contacts exceeding that limit. > >> if it is case 2, it would be nice if we know the total touches. >> Reporting it only once in the kernel would be enough since it would be >> a constant during its life time (my concern is we would need to repeat >> the unchanged touches in this case); > > A kernel driver which supports tracking_id does not have to send unchanged > data > for the contact, only the id itself. This would automatically be the case if > we > had MT event filtering in place in the kernel. I should clarify this in the MT > documentation. > > Even so, I can see that the concern here is about bandwidth. Imagine a device > which supports 1000 contacts, with tracking_id in hardware. Each packet would > then contain at least the 1000 ABS_MT_TRACKING_ID events and 1000 > SYN_MT_REPORT > syncs. For such a device, one might consider adding something like an > ABS_MT_ACTION event to the protocol, allowing drivers to send the list of > modified contacts. But we are not there yet, and we can just as well pass that > bridge when we get there. > >> if it is case 3, I think we could consider each blob as an >> finger/touch group. Then reporting the number of blob/fingers as well >> as number of contacts in the blob would make sense too. > > I believe the available hardware capabilities will ultimately decide what > possible additions there will be for the multi-user case. > >> The Multi-touch (MT) Protocol might have already provided everything I >> need. But I have to understand it to use it appropriately. > > Hope this helps. > > Cheers, > Henrik > > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
