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

[Elias Pschernig <elias@xxxxxxxxxx>]

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