https://bugs.winehq.org/show_bug.cgi?id=50864
--- Comment #11 from Henri Verbeet hverbeet@gmail.com --- (In reply to bastian.beischer from comment #9)
(In reply to Henri Verbeet from comment #8)
- Why is GLXBadFBConfig generated in the first place? Is it caused by a
bug/issue in Wine or Mesa, or is it a legitimate error caused by e.g. the driver not supporting the requested context version?
The mesa developers seem to be of the opinion that it is a legitimate error. I'm not familiar enough with mesa to have an opinion myself.
It may very well be, and if we got there through X11DRV_wglCreateContextAttribsARB(), that's a fair bit more likely. Still, it's useful to know why things happen.
The patch suggested by Adam Jackson on January 27 (seemingly no commentnumbers in gitlab?) would be fine in principle, but doesn't make a lot of sense on first sight; when create_glxcontext() is called from glxdrv_wglCreateContext(), "context->gl3_context" would be FALSE, and glXCreateContextAttribsARB() would not be used. Similarly, even if we did get there, I'd expect glXCreateContextAttribsARB() to be called with a NULL attribute list.
In the case of the backtrace posted by "swm" on April 7 we indeed*don't* go through glxdrv_wglCreateContext(), and create_glxcontext() gets called from X11DRV_wglCreateContextAttribsARB() instead. A potential GLXBadFBConfig would be expected there, but should get handled by the error handler we install.
I think you might be right, I will debug a bit more to confirm your position. I guess the reason they suggested to move the error handler was that they assumed none was installed in the critical code path, note that the backtrace provided by swm was not available at that time.
Right, it wasn't necessarily a bad thing to try; the "context->gl3_context" thing is perhaps a little subtle, particularly when you're unable to reproduce the issue yourself.
- Why does the serial of the generated error match a request previous to
the glXCreateContextAttribsARB() call? And why would that not be a Mesa/X11 bug?
That's what I tried to ask them as well ("is it wrong for mesa to expect that the request number was increased"). I guess the situation is that no actual request was sent to the X server. Instead the error is issued based on analysis of other data. And I don't know if that is valid. It might not be, purely because each error should have be associated with a unique serial number. Is that what you're saying?
Kind of. What currently seems to happen is that the reported error gets the serial of a previous, unrelated, request. From Wine's point of view, we don't particularly care about the exact serial, but if we were to do the following:
s1 = NextRequest(display); glXCreateContextAttribsARB(...); s2 = NextRequest(display);
the serial of the reported error should be >= s1, and < s2. Specifically because we don't want errors from unrelated requests to cause the current call to fail, or alternatively, ignore errors that shouldn't be ignored. We don't want to sprinkle XSync() calls all over the code either. Inserting an XNoOp() as you did seems fine in that regard.
For reference: https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Using_the_D...