lkml.org 
[lkml]   [2010]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@seas.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@euromail.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-----


\
 
 \ /
  Last update: 2010-05-20 02:31    [W:0.078 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site