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

[Peter Hutterer]

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.

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.
I don't want any client to rely on the tracking ID in the valuator
information, not even short term.

Cheers,
  Peter

> >>On the other hand, some devices carry a tiny be of extra information 
> >>through the specific contact id's, and they are not strictly the lowest 
> >>set of numbers needed to express the contacts that
> >>are active or have been activated since the last period of inactivity.  
> >>From what I've heard the magic mouse (again) is one such example.  I 
> >>haven't actually poked around enough to see it.
> >
> >do you have any info on what this extra information could be?
> 
> See above ;) Also, the magicmouse retains the last position of each 
> contact and tries to reuse it when possible.
> 
> Cheers,
> Benjamin
> 
> >
> >>
> >>Personally I haven't yet come up with or heard an argument for caring 
> >>about the real tracking id values and every usage case I've come up with, 
> >>it would seem just as easily served computing it
> >>from in the client.  However, I also know that I'm insufficiently 
> >>creative to eliminate the possibility that someone else would have a good 
> >>reason down the line.  Would it make sense to leave
> >>it as an option?
> >>
> >>
> >>I'd like to see these patches accepted.  Like Chase, I'm concerned how 
> >>this
> >will interact with the DID discussion.  Would it make sense to apply it in 
> >a
> >branch at very least so Ben doesn't have
> >>to continualy maintain the changes while the discussion rolls on.
> >
> >I expect it to provide some useful information once people start playing 
> >with
> >it. It may not be the final approach but meanwhile, any info we can get on 
> >how
> >we can handle input better is useful. Besides, the DID implementaion is 
> >quite a
> >bit off, as far as I can tell.
> >
> >
>