On 6/28/2010 9:23 PM, Henrik Rydberg wrote: > 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]. > What is the full set of anonymous contacts? It needs the description of case sending event for a finger going away. > 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
