[RFC] Multitouch support, step one

[Ping Cheng]

On Fri, Mar 19, 2010 at 3:28 AM, Henrik Rydberg <rydberg at euromail.se> wrote:
> Rafi Rubin wrote:
>> Of course this doesn't make as much sense if we follow Henrik's argument about
>> suppressing motion until the current values have changed enough.  But there
>> again, do we emit just the one contact or the whole group?  If the whole group,
>> then my argument stands.  As for reporting only subsets of the contacts as
>> needed, we would either have to move tracking to the kernel, or be pretty
>> careful about the conditions for "enough".
>
> 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?


As far as I understand the _MT_ case, it work like this: if we have a
tracking ID, we don't have to report the whole group.  If we don't
have an ID for individual touch, we would have to report the whole
group otherwise we would have problem to match the ones in the last
group with the ones in the current group.

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.


>> Much of that would simply be covered by the addition of a "contact
>> count" event (though clearly in some cases
>> that value needs double checking from what the hardware reports).
>
> I have thought about adding the contact count to the MT event stream for said
> reasons, but I really, really, do not want to change the API unless it is
> extremely necessary.

Reporting contact count in the kernel (driver) offers a generic way to
keep track of how many touches we may expect even before we receive
the real _MT_ events.  If we don't have this count, X driver or user
land application would have to retrieve the count case by case from
the hardware or by some other device specific means.  From a device
driver (both kernel and X server) developer's point of view, changing
kernel API now resolves a lot of issues downstream.

Ping