multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

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

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.

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.

> Do you need anything else from us to get the packages into natty?

Yes, but it's late so I'll leave this for another time :).

> As far as we can see from our side, there are two issues left:
> 
> The first is that running the games with software rendering is really slow. Currently, this applies to all computers with NVidia cards, since the proprietary drivers haven't been updated yet. Obviously, that should fix itself. Gameplay is nice and smooth on Ubuntu 10.10 with libmtdev support.
> 
> The second is that with mesa rendering, libstdc++ and mesa interact to cause a segfault on start. It can be worked around with export LD_PRELOAD=libstdc++, but that's obviously not a general solution. Here is the old bug report on launchpad - it's still accurate:
>     https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
> And this is what we're doing about it right now:
>     https://www.libavg.de/wiki/index.php/Known_Linux_Installation_Issues#glibc_invalid_pointer

Hmm, that's too bad. May I suggest hiding your game binaries as
/usr/bin/empcommand.real, and then having /usr/bin/empcommand be a
script that sets the env var and then executes the real binary? It's
hackish, but I've seen people do this type of thing before. There may be
better ways if you ask people on #ubuntu-devel or on the ubuntu-devel
mailing list.

Thanks!

-- Chase