Re: > 1) Seg. Fault and Xlib: unexpected async reply (sequence 0x1728)! Re: Re: I remember seeing problems like this when I was debugging multi-threaded Re: apps. Does XMMS use threads in conjunction with OpenGL?
Yes sir, OpenGL + threads. The error above is, like you said due to concurrent Xlib access (without using your suggested, in a later response, XInitThreads()). Re: > 2) Gdk-ERROR **: BadValue (integer parameter out of range for operation) serial 45 error_code 2 request_code 147 minor_code 13 I recon the above is also related, but Gdk errors are no help. Anyone else seen these? Re: I seem to recall the order of glXDestroyContext and XDestroyWindow did matter Re: but I thought I had fixed that a long time ago in the client-side DRI code. Re: I suggest you send your patch to the xmms developers (or whoever) since it Re: looks like a good work-around. Great. So these ordering issue can/is a driver issue from what you are saying? But it should have been fixed already, correct? If so, is it really fixed, or is the assumption that it's a driver issue wrong? This is really important because you guys developing the DRI should clarify for us the "proper" way of using the DRI/glX/X11 in conjunction with threads. Please, verify for me that either: 1) the calling order was fine to begin with (the driver should have handled it) or 2) the calling order was wrong to begin with. it should never Destroy the display before calling glXDestroyContext(). I really need a clear-cut answer here, because the XMMS folks are waiting for me to clear this up as well.. The suggested fix btw (reversing the calling order) was already handed from me to the developers before I posted on this list, and is already in the CVS, but we really should know the proper way so we can "clean up" the code :) Thanks in advance Re: > PS. does glXDestroyContext do a glFlush() or waits for buffers to empty or hardware to be quiescent (sp?) or does it just return immediately? Re: Re: I don't recall. Is this something I can find in the DRI code, or Mesa code? (Unfort. the man pages on the call don't say anything about flushing/state of hardware. I assume this also depends on the implementation of the GL and 3D drivers, aka AcceleratedX might act differently?) Re: > The docs say about it being active in the current thread, but does that include the GL drivers? Re: Re: Huh? Sorry for being unclear, I meant the man pages on glXDestroyContext() said nothing about flushing/etc Thanks so much for the response Brian. It validates some of the suspicions we had and will lead to making cleaner and better code (now I can recognize more easily thread-related GL issues, perhaps I can debug other situations). -- Get your free email from www.linuxmail.org Powered by Outblaze _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
