Message-ID: <4BF48198.4090300@seas.upenn.edu>
Date:	Wed, 19 May 2010 20:26:00 -0400
From:	Rafi Rubin <rafi@...s.upenn.edu>
To:	Ping Cheng <pinglinux@...il.com>
CC:	Henrik Rydberg <rydberg@...omail.se>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mika Kuoppala <mika.kuoppala@...ia.com>,
	Peter Hutterer <peter.hutterer@...-t.net>,
	Benjamin Tissoires <tissoire@...a.fr>,
	Stephane Chatty <chatty@...c.fr>,
	Michael Poole <mdpoole@...ilus.org>, rafi@...s.upenn.edu
Subject: Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/19/10 20:13, Ping Cheng wrote:
> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@...s.upenn.edu> wrote:
>> My understanding is that it would be more like
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
> 
> You are right if one slot only has or is only allowed to have one
> point. My scenario is that one slot can have more than one point.
> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
> in such a way that it avoids as much overlap as possible.
> 
> And hopefully it makes sesne in the reality too.

Please clarify by what you mean by more than one point.

I may be misunderstanding, but I thought that these slots are basically a
superior replacement to tracking id.

one finger -> one slot

But with slots we can use the filtering that input provides, which we've been
by-passing with the existing MT protocol (at least that's what I think Henrik's
goal is).

Rafi

>> (2 events from 1 finger, followed by 1 event with both).
>>
>>
>> On 05/19/2010 06:43 PM, Ping Cheng wrote:
>>>
>>> Hi Henrik,
>>>
>>> I am trying to link the protocol to the actual multi-touch devices in
>>> my "mind". Hope it helps you to point out the mismatch between my
>>> imagination and the protocol.  Please see details in line.
>>>
>>> Ping
>>>
>>> On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg@...omail.se>
>>>  wrote:
>>>>
>>>> This patch adds documentation for the SYN_MT_SLOT event and
>>>> gives examples of how to use the event slot protocol.
>>>
>>> Am I right in thinking that SYN_MT_SLOT represents to the actual touch
>>> area/finger on the surface? There could be more than one (x,y) (a few
>>> points that form an irregular shape) that represents one finger.  The
>>> following example shows that slot 0 (finger 1) touched three points on
>>> the surface while slot 1 (finger 2) only has one point reported:
>>>
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_TRACKING_ID 45
>>> +   ABS_MT_POSITION_X x[0]
>>> +   ABS_MT_POSITION_Y y[0]
>>> +   ABS_MT_TRACKING_ID 46
>>> +   ABS_MT_POSITION_X x[1]
>>> +   ABS_MT_POSITION_Y y[1]
>>> +   ABS_MT_TRACKING_ID 47
>>> +   ABS_MT_POSITION_X x[2]
>>> +   ABS_MT_POSITION_Y y[2]
>>> +   SYN_MT_SLOT 1
>>> +   ABS_MT_TRACKING_ID 30
>>> +   ABS_MT_POSITION_X x[3]
>>> +   ABS_MT_POSITION_Y y[3]
>>> +   SYN_REPORT
>>>
>>> If my assumption is correct, i.e., one slot can have more than one
>>> point, I would think ABS_MT_TRACKING_ID may not have to be a required
>>> entry inside SYN_MT_SLOT.  To the user land clients/drivers,
>>> SYN_MT_SLOT itself could serve as an ID. So, the following case is
>>> also a type B ( we know there are two touch areas. But we don't keep
>>> track of the points inside the areas):
>>>
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x[0]
>>> +   ABS_MT_POSITION_Y y[0]
>>> +   ABS_MT_POSITION_X x[1]
>>> +   ABS_MT_POSITION_Y y[1]
>>> +   ABS_MT_POSITION_X x[2]
>>> +   ABS_MT_POSITION_Y y[2]
>>> +   SYN_MT_SLOT 1
>>> +   ABS_MT_POSITION_X x[3]
>>> +   ABS_MT_POSITION_Y y[3]
>>> +   SYN_REPORT
>>>
>>> So, an EVIO for X driver to retrieve the number of SLOTs would be very
>>> helpful.  Something like the following would do the work:
>>>
>>> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
>>>
>>> which tells the user land clients that they can expect up to 13 touch
>>> areas.
>>>
>>>> +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,
>>>
>>> With what I said above, I think ABS_MT_TRACKING_ID is not the unique
>>> identifier for type B protocol. It is the fact that we can identify
>>> individual touch areas and use ABS_MT_SLOT to report them that makes
>>> it a type B event.
>>>
>>>> ABS_MT_TRACKING_ID, either provided by the
>>>> +hardware of computed from the raw data [5].
>>>
>>>                    ^^ or  (is it?)
>>>
>>> I agree with this ABS_MT_TRACKING_ID definition.  I would think something
>>> like:
>>>
>>> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
>>>
>>> which tells the clients that total of 48 points are tracked, would be
>>> helpful.
>>>
>>> Another topic that may be irrelevant to this patch is the filter. With
>>> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
>>> useless repeated points or less than a certain number of points
>>> movement.
>>>
>>
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv0gZgACgkQwuRiAT9o60/v5QCguYH/eGD4R12cIPGc/AF3Xz6Y
RXgAoIfEYSVqekbLRU4NXHo0bnG323vA
=OUmf
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists