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

[Benjamin Tissoires]

Le 17/06/2010 10:58, Henrik Rydberg a écrit :
> 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.
>

Hi Henrik,

This is great. We will have a common protocol even if the "old" drivers 
are not up to date.

I don't think we should change the current patchwork (or we may just 
remove the MT_SYNC handling when we will be sure that no one use it 
anymore). I had written these patches with the protocol B in mind: it's 
as simple as possible to handle protocol A without interfering with the 
B one: I have no tracking, no heavy computations, no states, etc...

So I can just start handling the protocol B in my own repository.

Thanks for your efforts

Cheers,
Benjamin