On 09/28/2010 09:37 PM, Stéphane Chatty wrote:

Le 28 sept. 10 à 21:10, Henrik Rydberg a écrit :

quoted

On 09/28/2010 08:49 PM, Stéphane Chatty wrote:
[...]

quoted

quoted

quoted

This usage of ABS_MT_TRACKING_ID is not ideal. The HID contact id normally maps
to a slot number, which suggests the MT slots protocol be used instead.

I'm working on a slot-based version of the Stantum driver, and have had a look
into this. The Stantum firmware actually cycles over 8-bit values for its
ContactID. In this, it conforms more to the definition you gave for
ABS_MT_TRACKING_ID ("The slot protocol requires the use of the
ABS_MT_TRACKING_ID, either provided by the hardware or computed from the raw
data [5]") than to a slot number, doesn't it? Nevertheless, given our recent
exchanges about the 3M driver, I planned to use the driver's own tracking ID.

Your thoughts?

Excellent. :-) Speaking of drivers and multiplication, I think many of the
current drivers could in fact be merged. It seems we have two or three different
types so far, and different manufacturers may well be served by the same driver.

Yes, I have started reviewing all devices and making a summary of their
differences in that very purpose. Among the things we'll need is some standard
way for calling the filtering function at the end of a set of fingers.
CONTACTCOUNT is a good candidate, but I need to check some devices. One thing
bothers me though. It is that hid-core has the whole information, then is splits
it and calls us repeatedly, then we more or less undo that by storing the
information and trying to determine the last time it calls us.

Right. A hid-mt device based on the raw protocol could be a good idea - after we
reduced the current set a bit. :-)

Cheers,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html