Dark Avenger wrote: > > 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?
I believe so. But since older versions of XFree86 may still be in use, it's a good idea to keep the re-ordered glXDestroyContext / XDestroyWindow calls. > 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(). The order should not matter. But to be safe, use the ordering which fixed the bug for you. > 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? It would be in the client-side DRI code. I just don't have time to research this. > (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). -Brian _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
