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

[Peter Hutterer]

On Fri, Jun 18, 2010 at 08:55:53AM +0200, Benjamin Tissoires wrote:
> 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...

I agree, I think the patches should go in for now as they are. Then we can
introduce the dependency on mtdev. I'm somewhat hesitant to delay the
patches even further for a completely new project, the bottleneck that
I am ATM is bad enough.

Cheers,
  Peter