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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Thu, 2008-08-14 at 18:31 +0200, Elias Pschernig wrote:
> 
> 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.
> 

Indeed, it breaks of course now when user OpenGL code calls
glBindFramebuffer, as does even exnew_opengl (which is a good thing,
made me realize it right now). So I went ahead and implemented the
two-x11-connections idea above. Case closed. (Hopefully.)

-- 
Elias Pschernig <elias@xxxxxxxxxx>





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/