Enabling multitouch in input-evdev

[Peter Hutterer]

On Tue, Jan 19, 2010 at 08:42:47AM +0100, Bradley T. Hughes wrote:
> On 01/18/2010 04:33 AM, ext Peter Hutterer wrote:
> >On Thu, Jan 14, 2010 at 11:23:23AM +0100, Bradley T. Hughes wrote:
> >>On 01/12/2010 12:03 PM, ext Peter Hutterer wrote:
> >>>>So, first question: is my behavior the good one? (not being
> >>>>compliant with Windows or MacOS)
> >>>
> >>>Short answer - no. Long answer - sort-of.
> >>>
> >>>Multitouch in X is currently limited by the lack of multitouch events in the
> >>>protocol. What you put into evdev is a way around it to get multitouch-like
> >>>features through a multipointer system. As Bradley said, it is likely better
> >>>for the client-side to include the lot in a single event.  Since X
> >>>essentially exists to make GUI applications easier (this may come as a
> >>>surprise to many), I'd go with his stance.
> >>>
> >>>However, this is the harder bit and would require changing the driver, parts
> >>>of the X servers's input system, the protocol and the libraries. It'd be
> >>>about as wide-reaching as MPX though I hope that there is significantly less
> >>>rework needed in the input subsystem now.
> >>
> >>Why do you think it would require protocol changes? For the new
> >>event type? If I understand it correctly, events for devices can
> >>contain any number of valuators... is it possible to have x1,y1
> >>x2,y2 x3,y3 and so-on?
> >
> >correct, there's a valuator limit of 36 but even that should be fine for a
> >single device. with axis labelling it's now even possible to simply claim:
> >hey, here's 24 axes but they represent 12 different touchpoints.
> 
> >I hadn't really thought about this approach yet because IMO touch is more
> >than just simply pairs of coordinates and that's what I'd eventually like to
> >get in.
> 
> Understood.
> 
> > As an intermediate option your approach would definitely work, it'd
> >be easy to integrate and should hold up with the current system.
> 
> That was my thinking as well.
> 
> >bonus point is also that the core emulation automatically works on the first
> >touchpoint only, without any extra help.
> 
> This was my thinking as well, as well as not having to wrap my head
> around how to deal with multiple implicit grabs in the presence of
> multiple events.
> 
> >And whether more is needed (i.e. complex touch events) is something that can
> >be decided later when we have a bit more experience on what apps may need.
> >Stephane, do you have opinions on this?
> 
> I agree. I do know of people that have built their own multi-touch
> tables and are interested in multi-user interactions, so I suspect
> that we will see interest in this eventually.
> 
> >> From what I can tell, there are a number of challenges that would
> >>require driver and server changes. In particular, being able to do
> >>collaborative work on a large multi-touch surface requires the
> >>driver (or server, not sure which makes most sense) to be able to
> >>somehow split the touch points between multiple windows. This is
> >>something that we had to do in Qt at least.
> >
> >packing all coordinates into one event essentially makes it a single
> >point with auxiliary touchpoints. This is useful for a number of things
> >(most gestures that we see today like pinch and rotate should work in this
> >approach) but not useful once you have truly independent data from multiple
> >hands or users. that's when you have to do more flexible picking in the
> >server and that requires more work.
> >
> >given the easy case of a single user interacting with a surface:
> >with Qt as it is now, if you get all the coordinates in a single XI2 event,
> >would that work for you? or is there extra information you need?
> 
> That should work. Ideally I would like to also get some kind of
> indication from the device that it is a touch device, and what kind
> of touch device it is (it is a touchscreen or a touchpad? for
> example, we treat them slightly differently).

Well, given the right axis labels that's the indication then :)

Cheers,
  Peter