[PATCH evdev 0/3] Preliminary support of multitouch (rev4)

[Henrik Rydberg]

Peter Hutterer wrote:
> On Thu, Jun 10, 2010 at 05:47:57PM +0200, Benjamin Tissoires wrote:
>> Even if there is an interesting thread concerning the use of multitouch on xorg-devel,
>> I still send the up-to-date patches to enable multitouch as valuators.
>>
>> Changes since last time:
>>
>> * Remove the detection of the maximum number of touches based on the tracking ID
>> * changes in comments
> 
> Henrik, Rafi, others - any further comments on this? Patches look good to
> me, with a minor issue (see below) that can be fixed in a follow-up patch.
> 
> Benjamin - I'm not sure exposing the tracking ID in a valuator is a good
> long-term solution. Does it provide any info that we do not already have by
> splitting the touchpoints into different valuators?
> 
> Cheers,
>   Peter

Hi Peter, Benjamin, Carlos,

I have a proposition to make, which might affect the Xevdev patchwork somewhat.
Referencing our discussion in March, one major issue was how to resolve the
kernel events into tracked contacts, before putting them onto the valuators. I
think there is now a solution for it, which can be summarized as:

1. Extract the kernel events
2. Run them through the mtdev converter
3. Extract them as slotted type B events
4. Use the Valuators as slots

Point 1 is all done, no problems there.

The bulk of point 2 is also done, which may come as a surprise. Within a couple
of days, there will be a git tree with a project called mtdev, which is a
standalone converter module, under a free license (MIT/BSD/LGPL), which
transforms all variants of kernel MT events to the slotted type B protocol. This
means that for a device without finger tracking, the tracking is done in
software. For devices with finger tracking, the data is simply transformed. For
devices utilizing the new MT slots, the data goes straight through. Point is, by
sending the events through mtdev, we gain a uniform source of MT events, which
is compatible with the Valuator approach.

This obviously affects the Xevdev code, point 3. However, the effect should be
that the parsing code is simplified, since handling the MT slots is inherently
easier than handling the type A protocol.

Point 4 may or may not be different from what you all had in mind already. By
using the valuators as regular MT slots, much of the ground work is already
done. The protocol is documented, the process is simple, and there is a
mechanism for dealing with adding/modifying/removing contacts.

Comments are very much welcome.

Cheers,
Henrik