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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
