http://bugs.winehq.org/show_bug.cgi?id=26763
--- Comment #13 from Roderick Colenbrander thunderbird2k@gmail.com 2011-04-26 18:30:40 CDT --- This part of the log clearly shows the 'failure': trace:wgl:ConvertAttribWGLtoGLX pAttr[0] = 2010 trace:wgl:ConvertAttribWGLtoGLX pAttr[1] = WGL_SUPPORT_OPENGL_ARB: 1 trace:wgl:ConvertAttribWGLtoGLX pAttr[2] = 2015 trace:wgl:ConvertAttribWGLtoGLX pAttr[3] = GLX_RED_SIZE: 8 trace:wgl:ConvertAttribWGLtoGLX pAttr[4] = 2017 trace:wgl:ConvertAttribWGLtoGLX pAttr[5] = GLX_GREEN_SIZE: 8 trace:wgl:ConvertAttribWGLtoGLX pAttr[6] = 2019 trace:wgl:ConvertAttribWGLtoGLX pAttr[7] = GLX_BLUE_SIZE: 8 trace:wgl:ConvertAttribWGLtoGLX pAttr[8] = 201b trace:wgl:ConvertAttribWGLtoGLX pAttr[9] = GLX_ALPHA_SIZE: 8 trace:wgl:ConvertAttribWGLtoGLX pAttr[10] = 2022 trace:wgl:ConvertAttribWGLtoGLX pAttr[11] = GLX_DEPTH_SIZE: 24 trace:wgl:ConvertAttribWGLtoGLX pAttr[12] = 2023 trace:wgl:ConvertAttribWGLtoGLX pAttr[13] = GLX_STENCIL_SIZE: 8 trace:wgl:ConvertAttribWGLtoGLX pAttr[14] = 2011 trace:wgl:ConvertAttribWGLtoGLX pAttr[15] = GLX_DOUBLEBUFFER: 1 trace:wgl:ConvertAttribWGLtoGLX pAttr[?] = GLX_DRAWABLE_TYPE: 0xffffffff trace:wgl:ConvertAttribWGLtoGLX pAttr[?] = GLX_RENDER_TYPE: 0xffffffff warn:wgl:X11DRV_wglChoosePixelFormatARB Compatible Pixel Format not found
I have an idea on what's wrong though and after another read of the GLX specs, I think it is a Mesa bug. Just in case can you attach the output of 'glxinfo -c'?
ConvertAttribWGLtoGLX is used as part of wglChoosePixelFormatARB which the game uses to select a 'pixel format' to use for its OpenGL window. In Wine we use glXChooseFBConfig to implement this call. In case of WGL if you don't specify a 'drawable type' it returns formats for all types of drawables it can support (window, bitmap, pbuffer), but GLX only returns info for windows. If I remember correctly this patch was for a part needed to make fglrx happy and to make things more correctly.
The problem is that Mesa doesn't like me passing in '0xffffffff' as the GLX_DRAWABLE_TYPE (actually it dislikes RENDER_TYPE of 0xffffffff as well). In the end Mesa does about the following in its fbconfig checking:
for(i=0; i<config_list_size; i++) fbconfigs_compatible(requested_config, config_list[i]);
static int fbconfigs_compatible(config *a, config *b) { ... MATCH_EXACT(level);
MATCH_MASK(drawableType); MATCH_MASK(renderType); ... }
where MATCH_MASK: #define MATCH_MASK(param) do { if ((a->param & ~b->param) != 0) return False; } while (0);
The problem is that the configurations in config_list have at max a few bits set (e.g. GLX_WINDOW_BIT | GLX_PIXMAP_BIT | GLX_PBUFFER_BIT) while I'm passing in ~0 (which is equal to GLX_DONT_CARE). Because a different number of bits is set in a->param and b->param, MATCH_MASK fails and no configuration gets selected.
There are two things in the GLX specs. First of all it mentions that when you pass a bitmask to glXChooseFBConfig ALL bits set in the mask have to match. The second thing it mentions is that if GLX_DONT_CARE is specified as a value for one of the attributes (which is the case here), the option in question should be ignored.
Some of the other MATCH_ macros in Mesa check for GLX_DONT_CARE, but not the MATCH_MASK one, so I would guess the bug is there but I don't have a Mesa system to test on. I could write a quick test app. (I could also just not set GLX_RENDER_TYPE / GLX_DRAWABLE_TYPE when either of the two is 0, but not sure what sort of issues that may cause ..)