[RFC] Multitouch support, step one

[Rafi Rubin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/20/10 01:58, Ping Cheng wrote:
> 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.

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

For a tracked group, or even just a subset of active tracked contacts that have
changed.  Emit tracking id for the first contact to signal the set is tracked.
Then for each subsequent contact, if the ID is just 1 greater than the previous,
don't bother sending anything.  If the id's are not sequential, report the
difference from the previous contact.

If we can take that a step further, if the downstream is aware that we are
tracking contacts, the first tracking ID is only needed if its non-zero.


Good old run length encoding to minimize tracking id bandwidth.


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

I agree, there should be a MT capabilities with fields for max contacts and
tracking trustworthiness, not sure what else.

Rafi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkulKpAACgkQwuRiAT9o60/7awCfQNsHl9mxJfMLwooiEP2R0X4B
60oAoICNFI/meARYyPSFgu+HQ84FizQ6
=yQ3e
-----END PGP SIGNATURE-----