Re: [AD] Missing field in keyboard and mouse events

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Thursday 14 August 2008, Elias Pschernig wrote:
> On Wed, 2008-08-13 at 19:21 +0200, Elias Pschernig wrote:
> > I'm also right now investigating some locking problems I get from X11
> > with that patch. Seems with the A4 background thread using its own X11
> > connection to do some of the setup, those were less likely to occur.
> > Using the A4 events thread model (poll for X11 events 1000 times a
> > second, protected by a lock, instad of just XNextEvent) makes them
> > disappear again, but I think there will be an easy solution without
> > reverting to that.
>
> Hm, messing with those X11 events was a major dejavu from a few years
> ago for me. I kinda had remembered from back then that X11 was about to
> get more thread safe, but seems I was wrong. 

You weren't. You just can't use libX11. Instead we have to update to XCB. 
Which we really should..

> I did get things working
> here now and committed a revised patch - but only by making the events
> thread lock out its X11 calls (especially XNextEvent) again, which also
> means XNextEvent can not block again. I really don't like it, but the
> situation is essentially the same as the other times we discussed this
> in the past.
>
> Basically, X11 seems to not be fully thread-safe. It did work somewhat
> better before this patch as keyboard and mouse were using a separate
> display connection from the old A4 driver. So maybe this could be
> somehow abused, I think I already played with that idea a few years ago
> - basically use one X11 connection to do graphics output (which the user
> can use from the main thread, unlocked), and another for the rest
> (wrapped by XLOCK/XUNLOCK).
>
> Anyway, I got it to a state here right now with a single X11 connection
> where I can't reproduce any xcb sloppy lock assertions. But among other
> things it meant putting glBindFramebufferEXT inside a lock, as
> apparently it calls a non-thread-safe X11 functions internally - so this
> shows how unstable this solution might be.. but if testing by others
> shows no problems, I guess we could go on with it.
>
> --
> Elias Pschernig <elias@xxxxxxxxxx>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx