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 _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : multi-touch-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
