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. -- 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
