MPX and multitouch

Peter Clifton pcjc2 at
Wed May 14 09:06:31 PDT 2008

On Thu, 2008-05-15 at 00:00 +0900, Jordi Polo wrote:
> I have been thinking about an architecture for gestures etc. And it is
> difficult to make it out of the toolkits. 
> Basically, the toolkits already have an event loop where they take
> events from X. 
> It is easy to implement mouse gestures for simple and multi pointers
> there. 
> multitouch gestures, they much more difficult but I don't see good
> reasons to move them outside that even loop.

libstroke works by having you pass coordinates from the mouse events to

stroke_record (int x, int y);

I'd suggest that the library should concentrate on the processing logic
required to recognise gestures from an abstract representation of the
motion paths and event sequences returned.

It is those processes / heuristics which must ideally be consistent
across the platform. I don't know what information they need for the
multi-touch case, whether it should be real-time updated, or if various
touch vs. time paths can be sent and post-processed.

Beyond this, there will need to be toolkit (or application) dependant
ways to hook into the X events, and choose whether to pass them on or
absorb them.

I'm afraid I'm not familiar with multi-touch gestures. In gEDA/gschem,
libstroke is used and bound to a particular mouse button, so gEDA
explicitly passes motion events to libstroke for analysis, thus there is
no conflict between events which might make up a gesture, and other
actions tied to that mouse button.

> Also, I don't even know how to do it. Having a library that intercepts
> mouse events process them and send their events?
> And toolkits will receive mouse events and a delayed (processing)
> gesture event and they should figure out is the same thing? or that
> library will filter the mouse events ? is it possible? will toolkits
> use it?

Given a touch-screen device.. I guess it will take time to determine
whether a sequence of events is a tap, or a particular gesture.

Whether tool-kits will use it.. pass. It could be an input module or
similar, setup for a particular hardware device, in which case -
"perhaps", but I think there is another useful case, where applications
may want to use it, or at least control its behaviour.

Best wishes,

Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,

Tel: +44 (0)7729 980173 - (No signal in the lab!)

More information about the xorg mailing list