https://bugs.winehq.org/show_bug.cgi?id=50864
--- Comment #9 from bastian.beischer@rwth-aachen.de --- (In reply to Henri Verbeet from comment #8)
Frankly, I don't find the Mesa report all that clear, although part of that may just be gitlab. In any case, the concrete questions I have are the following:
Right - there certainly is a bit of history there. Sorry about that.
- 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.
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.
In reality, at least when going through X11DRV_wglCreateContextAttribsARB(), the error handler is installed, but doesn't function because the serial number of the error was not increased.
- 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?
The mesa developer suggested to wrap the call to
pglXCreateContextAttribsARB
in dlls/winex11.drv/opengl.c (create_context function)
in X11DRV_expect_error in order to turn the error into a warning. I think this is a fine solution. However, X11DRV_expect_error only works if a X server request is made, which does not happen in this case (see the mesa gitlab ticket).
Moving the X11DRV_expect_error() call to create_glxcontext() might be fine, but it's not clear to me that it should be needed. The backtrace by "swm" and your (you're Bastian Beranek on freedesktop gitlab, right?) comments on April 15 and 16 certainly suggest it isn't.
Yes, that's me.
The serial of the generated error pointing to a previous request seems like a clear bug, and I suspect that simply fixing that would allow the existing error handler to work as expected. If I'm overlooking something there please it out; it's not clear to me from the Mesa report.
I agree, if indeed it is correct to expect a unique serial number for each error.