multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On 02/23/2011 06:23 PM, Ulrich von Zadow wrote:
> On Feb 23, 2011, at 5:42 AM, Chase Douglas wrote:
>> On 02/22/2011 09:56 AM, Ulrich von Zadow wrote:
>> 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 :).
> 
> Clear so far. I'll have some time tomorrow or Friday to look into this
> (right now, my Natty alpha setup is broken beyond repair...), but I'll
> voice some thoughts & if answers pop into your head, I'd love to hear them.
> 
>>
>> 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.
> 
> Up to this point, things are clear to me.

I realized this won't actually work. The pointer grab is a grab that is
always active. Touch grabs are passive grabs that only activate when a
touch begins. So, the touch events will always be taken by the active
pointer grab before any passive touch grab can be activated.

We don't have any way to grab touches in the same manner as XGrabPointer
to always have an active grab. I don't think we really want that either :).

> We've avoided changing SDL so far (I sort of expected it to be hard to
> patch SDL just to get our stuff running ;-)). Actually, we had to code
> quite a bit around SDL's input handling, since SDL doesn't know anything
> about XInput 2.x. Here's our current code, if you're
> interested: https://www.libavg.de/websvn/filedetails.php?repname=libavg&path=%2Ftrunk%2Flibavg%2Fsrc%2Fplayer%2FXInput21MTEventSource.cpp
> <https://www.libavg.de/websvn/filedetails.php?repname=libavg&path=%2Ftrunk%2Flibavg%2Fsrc%2Fplayer%2FXInput21MTEventSource.cpp>

That's not too surprising :).

>> 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.
> 
> This is where I start getting confused a bit, but I assume that I can
> sort most of it out by myself once I have a running setup again.

As I noted above, this won't actually work, so that helps condense our
options some.

> Still, some questions:
> - The spec sais 'a device may not be grabbed through an XI2 grab if an
> XI1 grab is currently active on this device or vice versa.'. Are we
> running into this? SDL is doing exclusively XI1 processing.

Not really. Pointer and keyboard grabs are being handled sequentially as
noted above. Touch grabs shouldn't interfere with the ability to perform
a pointer grab and vice versa.

> - In your other mail, you mention using XIChangeHierarchy. If this is
> the only solution, we'll do it, but at the moment the games work in
> non-fullscreen mode as well and that's a real help when debugging.
> Although it does sound like that'd be the easiest solution to implement...

I think it's just one possible solution. The reason it works in
non-fullscreen mode is because SDL only grabs the pointer by default in
fullscreen mode. I think their reasoning is that if you have a cursor
controlled game and two monitors where the game is full screen on one
monitor, you want to keep the cursor confined to the game's window. The
SDL grab enforces this pointer confinement. I don't think event grabbing
semantics is as big of a concern for pointers as it is for keyboards.

Thinking about your games, none of them use the cursor I believe. Thus,
there's really no point to confining the pointer to the window, and the
fact you're using a touchscreen limits event grab necessity. The easiest
thing to do would be to disable the SDL grab by calling:

SDL_WM_GrabInput(SDL_GRAB_OFF);

Maybe that should go in XInput21MTEventSource::start()?

>> 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.
> 
> And this is where it starts being really confusing. We're watching for
> mouse events already. Some games hide the mouse cursor, but all of them
> should react to mouse events.

Maybe this means ungrabbing the pointer isn't the best route? If so,
then I think the only way to go forward is to either convert sdl to
XInput 2.1 so it can determine whether an event is pointer emulated
(probably too much trouble right now :), or to detach the touch device
when you start using it.

>> Or, maybe you can disable the pointer grab altogether? Your games all
>> are full screen, so I don't think this would be a big problem.
> 
> That would require changing SDL, right?

See comments above :).

Thanks!

-- Chase