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

[Peter Hutterer]

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


> 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?

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