multi-touch-dev team mailing list archive

["Henrik Rydberg" <rydberg@xxxxxxxxxxx>]

On Tue, Feb 22, 2011 at 11:42:34PM -0500, Chase Douglas wrote:
> On 02/22/2011 09:56 AM, Ulrich von Zadow wrote:
> > Hi everyone,
> > 
> > we have all multitouch games packaged and working with the updated XInput 2.1 API :-).
> > 
> > Installing python-libavg-games from OXullo's ppa (https://launchpad.net/~oxullo/+archive/libavg) on top of the utouch stack should get everything running.
> 
> This is great! I tested them out tonight. In fact, it was good to test
> it out now because I found a crasher bug :). I believe you are using
> SDL, and it seems that SDL actively grabs the pointer when it starts.
> You've selected for touch events on the parent window of the SDL pointer
> grab window. In this specific circumstance, the current code will crash.
> I've fixed this up with a patch and sent it along to the ubuntu-x team
> as they are just about to push all of this into the Ubuntu archive. So,
> thanks for giving me more stuff to test!
> 
> However, this highlights an issue. I spent the last week and a half
> making touch events integrate into the pointer event stream, and this
> broke your games :). Basically, we do the following from the root window
> R to the top level window T to the child window C:
> 
> 1. Handle touch grab on R
> 2. Handle pointer grab on R
> 3. Handle touch grab on T
> 4. Handle pointer grab on T
> 5. Handle touch grab on C
> 6. Handle pointer grab on C
> 7. Handle touch and pointer select on C, stop if events delivered
> 8. Handle touch and pointer select on T, stop if events delivered
> 9. Handle touch and pointer select on R
> 
> In your applications, SDL seems to be asynchronously actively grabbing
> the pointer in what is analogous to window C above. An asynchronous grab
> at any grab point stops further delivery. So event delivery is ending at
> step 6 above, and never getting to step 8, which is where you have a
> touch selection. Note that this is only the case for the first touch,
> since it's the only one that is pointer emulated. I played your games by
> keeping a thumb always pressed to one of the corners of the screen as a
> workaround :).

How can a pointer grab stop a touch? A touch origins at a slave
device, and I can imagine grabbing the pointer of a master device fed
from that slave device. However, I cannot imagine that grab stopping
the slave device touches from being delivered to someone listening to
that device.
 
> There are ways to get around this, some easier than others. If you want
> to continue with SDL's grab approach, you could add a touch grab on the
> same window as the pointer grab. You could add this to the SDL code, or
> you could add it to your own code outside of SDL. However, the semantics
> for touch grabs are different from touch selections: you'll need to
> select for ownership and unowned update events. If this sounds like
> gibberish, let me know :). It should be all documented in the protocol
> spec in /usr/share/doc/x11proto-input-dev/XI2proto.txt.
> 
> There are many ways to skin this cat, so you could modify the pointer
> grab to replay the events if they are pointer emulated touch events. You
> can check this by looking at the flags field of the device event. Most
> likely, though, it's a core or XI 1.x grab, which would need to be
> converted to xi 2.1. It's probably more trouble than it's worth.
> 
> Another way would be to take the pointer events and translate them to
> touch events internally if they are pointer emulated. To determine
> whether they are pointer emulated would require converting them to XI
> 2.1 grabs again, though. But if you don't mind people trying to use a
> mouse, you could just translate all the mouse events.

Really, this sounds more complicated than it needs to be.

Henrik