[RFC] Multitouch support, step one

[Henrik Rydberg]

Ping Cheng wrote:
> 2010/3/20 Ping Cheng <pinglinux at gmail.com>:
>> 2010/3/20 Rafi Rubin <rafi at seas.upenn.edu>:
>>>>> The reporting is always for the whole group, since the contacts are
>>>>> interdependent. I do not see what argument stands because of this, nor the
>>>>> rationale behind it. Could you clarify, please?
>>>> If we consider to filter the data in the kernel, reporting ID from the
>>>> kernel is unavoidable.  Otherwise we would have to either filter the
>>>> whole group or report the whole group even if there is only one point
>>>> in the group changed significantly.
>>> Henrik expressed the assumption that the whole group would be transmitted
>>> together.  I had some thoughts about keeping or not keeping ID, but I have
>>> another idea.
>>>
>>> Why don't we just report delta(ID).
>> 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. 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.

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

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