https://bugs.winehq.org/show_bug.cgi?id=50864
--- Comment #8 from Henri Verbeet hverbeet@gmail.com --- (In reply to bastian.beischer from comment #7)
If you read https://gitlab.freedesktop.org/mesa/mesa/-/issues/3969 you will understand the details.
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:
- 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 patch suggested by Adam Jackson on January 27 (seemingly no comment numbers 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.
- 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?
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.
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.