On 10/29/2010 10:45 PM, Ping Cheng wrote: [...] >>> >>> Why do we need an arbitrary MAX_TRACKING_ID when the device can tell >>> us how many IDs we can have and it tracks the individual fingers for >>> us? The emphasis is on unique, not on arbitrary. :-) >>> In this case, there are only two ID/fingers and the ID can be >>> retrieved from the raw data. I must be missing something in the >>> defintion of MAX_TRACKING_ID. >> >> In the language of ABS_MT, there is a distinction between slot and id. The slot >> is the handle used to communicate a unique touch. The id is the identifier of >> that touch. The device tells us how many slots we have. The range of ids is in >> principle infinite. In practice, it is set to a large number. > > Sorry to bring this topic back again. I was under the impression that > I was the only one who didn't get the spec clear. The discussion at > yesterday's UDS session made me feel I am not alone (good or bad :). > Let me try it again to see if I can get it right this time. > > From the "Multi-touch (MT) Protocol" under Documentation/input, we see > the following: > > "The slot protocol requires the use of the ABS_MT_TRACKING_ID, either > provided by the hardware or computed from the raw data". > > That means if the hardware provides the tracking ID, we use it. > Otherwise we lose that specific information reported from the > hardware. The recurring question is: what information is lost? > For the Bamboo case, the tracking ID happens to be the same as the > slot ID we use. But, there are devices, as far as I know, report up to > 10 fingers/touches. So, there would be 10 slots to report the data. > But, the tracking ID we get from the devices is 0 to 255. So, slot 5 > could have a tracking ID of 123 now and 9 when tuch 123 is up and > touch 5 is down. > >> To answer a possible follow-up question: from the tracking id, you can tell if a >> contact is present, if it is new, and if it is older than another contact. > > The new and old attribute can be tracked by a time stamp in the > userland. Kernel driver doesn't need to worry about it. Maybe I am > missing an use case in the kernel? The kernel is the most long-lived process, and userspace programs may be restarted many times over during the life cycle of a single boot. What happens when we want to restart an application monitoring a large touch table, for instance? Regardless of what applications and needs we will see in the future, I feel the main argument put forward so far, that hardware information must be passed on untouched at all costs, is more political than technical, and I would very much like to stay out of such discussions. Thanks, Henrik -- 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
