multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On 02/23/2011 03:20 AM, Henrik Rydberg wrote:
> 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.

What you've described is correct for pointer devices, but not for touch
devices. A device grab is intended to yield exclusive access to the
stream of events from that device. Continuing to send touch events when
the stream of events has been pointer grabbed breaks this exclusivity. I
will think more about this though.

However, this reminds me of a different, potentially easier, solution.
For these games, you don't really want the pointer to be controlled by
the touchscreen. When you start up, you can use XIChangeHierarchy to
detach all touchscreens. This will inhibit them sending pointer events
at all. Then you should subscribe to XIAllDevices when you make your
touch selections. Just remember to be kind and reattach the touch
devices to the master pointer when you exit (including error exit paths).

>> 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.

No one would disagree :). Again, we're caught having to work within a
window system that forces us to integrate pointers and touches when that
should never be the case. And SDL is actively pointer grabbing all the
time, and whenever you do that things invariably get more complicated.

-- Chase