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

[Joonyoung Shim <jy0922.shim@samsung.com>]

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