[RFC] Multitouch support, step one

[Ping Cheng]

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?


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

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