Re: [PATCH v2] input: qt602240 - Add ATMEL QT602240 touchscreen driver

[Henrik Rydberg <rydberg@euromail.se>]

Joonyoung Shim wrote:
> On 6/28/2010 7:22 PM, Henrik Rydberg wrote:
>> Joonyoung Shim wrote:
>> [...]
>>> Do you mean to report the coordinates of contact __remaining__? You told 
>>> me at first, "The position should be the position where the finger left
>>> the surface", so i am confusing.
>> The two comments do not apply to the same situation. The latter comment was made
>> in the context of a tracking-capable device which sends one last event for a
>> finger going away. Transformed to the stateless type A protocol, that results in
>> (touch = 0, x = last value, y = last value). 
>> The former comment was in the
>> general context of the type A protocol, which has no notion of anything going
>> away. After you lift a finger and look at the state, what you see is the
>> remaining set of fingers.
>>
> 
> OK, i see, but i think it needs to add the latter comment on MT protocol 
> document to prevent some confusion.
> 

Something like this? Dmitry, would you please consider squashing this patch with
the 5b version, if Joonyoung concurs?

Thanks,
Henrik

---

diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/
index 3ab038d..bdcba15 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -43,15 +43,16 @@ input_sync() function. This instructs the receiver to act up
 accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set
 of events/packets.

-The main difference between the raw type A protocol and the higher level
-type B slot protocol lies in the usage of identifiable contacts. The slot
-protocol requires the use of the ABS_MT_TRACKING_ID, either provided by the
-hardware or computed from the raw data [5].
+The main difference between the stateless type A protocol and the stateful
+type B slot protocol lies in the usage of identifiable contacts to reduce
+the amount of data sent to userspace. The slot protocol requires the use of
+the ABS_MT_TRACKING_ID, either provided by the hardware or computed from
+the raw data [5].

 For type A devices, the kernel driver should generate an arbitrary
-enumeration of the set of anonymous contacts currently on the surface. The
-order in which the packets appear in the event stream is not important.
-Event filtering and finger tracking is left to user space [3].
+enumeration of the full set of anonymous contacts currently on the
+surface. The order in which the packets appear in the event stream is not
+important.  Event filtering and finger tracking is left to user space [3].

 For type B devices, the kernel driver should associate a slot with each
 identified contact, and use that slot to propagate changes for the contact.