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

[Peter Hutterer]

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).