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 _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel