[RFC] Multitouch support, step one

[Ping Cheng]

On Mon, Mar 22, 2010 at 5:22 PM, Ping Cheng <pinglinux at gmail.com> wrote:
> On Mon, Mar 22, 2010 at 4:57 PM, Henrik Rydberg <rydberg at euromail.se> wrote:
>> Ping Cheng wrote:
>>> 2010/3/20 Ping Cheng <pinglinux at gmail.com>:
>>>> I might have mistaken the definition of tracking ID here.
>>>
>>> After reading the Multi-touch (MT) Protocol again,  I think combining
>>> ABS_MT_TRACKING_ID with ABS_MT_BLOB_ID resolves my ID issue. So, I
>>> withdraw my support to add a software tracking ID in the kernel. I
>>> think ABS_MT_BLOB_ID serves as the software tracking ID, if I don't
>>> misunderstand the use of ABS_MT_BLOB_ID here.
>>
>> There are no drivers using the blob id currently, and it has a completely
>> different purpose.
>
> Thank you Henrik. It really helps. Can you explain a bit more of the
> purpose of ABS_MT_BLOB_ID?

Sorry everyone in the list for my repeated questions.  I know it is a
bit outside of the subject that Peter initiated in this thread. But,
understanding "every bit" of the protocol is very important to me.

Henrik, the questions are still for you, the protocol author (please
don't hate me :).

Am I correct in understanding that BLOB_ID reports a group of RAW
contacts received from the hardware, hence the need of
ABS_MT_SW_TRACKING_ID for the computed events?


>> The ABS_MT_TRACKING_ID is the only event that has to do with
>> finger tracking. By software tracking is meant code that computes that event,
>> such that it can be included in drivers that does not support it in hardware.
>
> I see. How are we going to report the computed events to the user land?

If we have ABS_MT_SW_TRACKING_ID, I know how to report the computed events.


>>> But, I reserve the request for a contact count in the kernel until I
>>> understand the definition of "the whole group".
>>> Henrik, by "the whole group", do you mean:
>>>
>>> 1.      all the contacts/fingers on the screen/surface at a certain time, or
>>> 2.      all the touch points supported by the hardware, or
>>> 3.      all the contacts defined in a blob?
>>
>> The first option, all present contacts.
>>
>>> If it is case 1, it would be nice if we (X driver or contact driver in
>>> your term :) know the total contacts the hardware support (if there is
>>> a limit) and how many contacts we are getting;
>>
>> The protocol defines a generic way of sending a variable amount of contacts. The
>> contact count is obtained by counting the number of non-empty finger packets
>> between SYN_REPORT events. To add a second way to obtain the same number would
>> be redundant.
>>
>> Regarding total contacts supported by the hardware, the protocol currently deals
>> with single-user finger contacts. The natural limitation is ten. :-) Yes, there
>> could be additional tools like pens available, and yes, maybe some devices
>> support multiple users as well, but generally, it is more a question of how many
>> contacts one wants to support in the X driver. One should be prepared to drop
>> contacts exceeding that limit.
>>
>>> if it is case 2, it would be nice if we know the total touches.
>>> Reporting it only once in the kernel would be enough since it would be
>>> a constant during its life time (my concern is we would need to repeat
>>> the unchanged touches in this case);
>>
>> A kernel driver which supports tracking_id does not have to send unchanged data
>> for the contact, only the id itself. This would automatically be the case if we
>> had MT event filtering in place in the kernel. I should clarify this in the MT
>> documentation.

Do you think it would encourge hardware vendors to provide a tracking
ID if we also change the two-finger touch example from:

   ABS_MT_POSITION_X
   ABS_MT_POSITION_Y
   SYN_MT_REPORT
   ABS_MT_POSITION_X
   ABS_MT_POSITION_Y
   SYN_MT_REPORT
   SYN_REPORT

to

when both fingers have changed positions significantly (assuming we
have a filter in place):

   ABS_MT_POSITION_X
   ABS_MT_POSITION_Y
   ABS_MT_TRACKING_ID (0)
   SYN_MT_REPORT
   ABS_MT_POSITION_X
   ABS_MT_POSITION_Y
   ABS_MT_TRACKING_ID (1)
   SYN_MT_REPORT
   SYN_REPORT

when only one finger changed position OR only one finger is touching
the surface and changed position

   ABS_MT_POSITION_X
   ABS_MT_POSITION_Y
   ABS_MT_TRACKING_ID (0/1)
   SYN_MT_REPORT
   SYN_REPORT

>> Even so, I can see that the concern here is about bandwidth. Imagine a device
>> which supports 1000 contacts, with tracking_id in hardware. Each packet would
>> then contain at least the 1000 ABS_MT_TRACKING_ID events and 1000 SYN_MT_REPORT
>> syncs. For such a device, one might consider adding something like an
>> ABS_MT_ACTION event to the protocol, allowing drivers to send the list of
>> modified contacts. But we are not there yet, and we can just as well pass that
>> bridge when we get there.

If this happens, I would think the ABS_MT_TRACKING_ID is unnecessary
any more. The (X,Y) would serve as a position ID since the data is
most probably covering the whole surface. Another value such as
pressure would be used to verify the changes.

Am I following you this time, Henrik?


>>> if it is case 3, I think we could consider each blob as an
>>> finger/touch group.  Then reporting the number of blob/fingers as well
>>> as number of contacts in the blob would make sense too.
>>
>> I believe the available hardware capabilities will ultimately decide what
>> possible additions there will be for the multi-user case.
>>
>>> The Multi-touch (MT) Protocol might have already provided everything I
>>> need. But I have to understand it to use it appropriately.
>>
>> Hope this helps.
>>
>> Cheers,
>> Henrik
>>
>>
>