On Fri, Jun 18, 2010 at 09:03:53AM +0200, Benjamin Tissoires wrote: > Le 18/06/2010 08:53, Peter Hutterer a écrit : > >On Fri, Jun 18, 2010 at 08:46:17AM +0200, Benjamin Tissoires wrote: > >>Le 18/06/2010 06:56, Peter Hutterer a ?crit : > >>>On Fri, Jun 18, 2010 at 12:18:00AM -0400, Rafi Rubin wrote: > >>>>On Thu, Jun 17, 2010 at 11:51:34AM -0400, Chase Douglas wrote: > >>>>>On Thu, 2010-06-17 at 12:16 +1000, 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. > >>>>> > >>>>>> From patch 2/3: > >>>>> +#define ABS_MT_X_VALUE 0x8 > >>>>> +#define ABS_MT_Y_VALUE 0x16 > >>>>>It looks like ABS_MT_Y_VALUE should be 0x10. > >>>> > >>>>:) > >> > >>Peter, would you correct it ? > > > >sure. > > > >>>> > >>>>>Overall this makes sense to me for devices where the MT data should be > >>>>>attached to the cursor (i.e. like a magicmouse). How will this mesh with > >>>>>direct input devices (or whatever mechanism is developed for multitouch > >>>>>touchscreens)? It seems to me we will need to somehow tell the module > >>>>>whether to pass the data as valuators or as DIDs, but not both. However, > >>>>>that's an implementation detail that can be worked out later when we get > >>>>>to it. > >>>>> > >>>>>>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? > >>>>> > >>>>>Why not expose the tracking ID? It's one less thing for the client to > >>>>>worry about if it needs to track touches. Without the ID, clients would > >>>>>have to implement their own tracking algorithms because they would just > >>>>>get an array of touches. The same finger will be sent in a different > >>>>>slot of the array on subsequent events, such as when a previous finger > >>>>>is removed. > >>>>> > >>>>>-- Chase > >>>> > >>>>I believe the argument against is that the valuators already carry that > >>>>information implicitly (eg axis 12 would be Y of the third contact and > >>>>would continue in that role even if there are no > >>>>active contacts 1 and 2). As such having another valuator would be > >>>>wasteful. > >>> > >>> > >>>yeah, it's superfluous and imo sending what is essentially an ID down an > >>>axis > >>>seems a bit odd at best. It's akin to sending a button number down as an > >>>axis. > >> > >>I agree with you, but only for the protocol that includes MT_SLOTS. As > >>the current patchwork deals with protocol A, and as this protocol > >>consists in a sort of pass-through (don't know if it's the word...) of > >>the device events, I think we should also send the trackingID. > >>When slots will be available, and the tracking will be done into the > >>kernel (or in mtdev), and Xinput2 masks will be available, we could just > >>drop the trackingID. But currently, for me, it's the only one solution > >>regards to the set of patches, as there is no tracking. > >> > >>Let's have en example: the magicmouse. This devices sends the touches in > >>order from the lowest to the highest, even if the contact 2 is newer > >>than the contact 4. With this current implementation, and without the > >>trackingID, the client will see the contact 4 jumped to where is the new > >>contact 2, and creates a new one to the old position of contact 4. > > > >why don't you work around this in the evdev driver then? that's the layer > >that > >should honor the tracking ID and convert it into what's essentially slot > >information. > > If I start having states (to keep the link between trackingID and > slots) into the Xevdev driver, this will conflict with the handling > of protocol B (the one that will be available soon). That's my > biggest and blocking point.
no. AFAUI, protocol A/B are mutually exclusive and since you know when B is available, you can switch the evdev-state tracking off and use slots in that case. Cheers, Peter > >I'd also request you have a look at adding the mask bits to the X server > >input > >APIs. Afaict, this is the only reason we can't do this now and it is quite > >fixable. > > will do. > > >I don't want any client to rely on the tracking ID in the valuator > >information, not even short term. > > Ok, I think you could just apply the patch 1/3 named "Add the names > of the valuators for the multitouch properties". This patch is > totally separated of the input handling, but just adds the names. > > We can wait a little for Henrik to publish mtdev and then just skip > the protocol A and directly apply protocol B (with slots and masks > available). _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
