Willie Sippel wrote:
Am Sonntag, 2. April 2006 16:44 schrieb Leon Freitag:
Someone mentioned earlier that the code in wgl.c in DescribeDrawable() violates the GLX specification and therefore causes bogus return values for the visualid. However this code has been already present before the regression, but worked somehow. So the regression can't be caused by this violation. I tried to correct this violation by calling glXChooseFBConfig and then glXGetChooseConfigAttrib, as suggested in the spec, and glXChooseFBConfig returns NULL for the appropriate FBCONFIG_ID.
To describe what I've seen: because the window isn't created using glXCreateWindow() it has no GLXFBConfig associated (at first), thus no valid FBCONFIG_ID (and because of that you can't find out the VISUAL_ID!), that seems reasonable because no GLX function has touched the drawable before. But that's only up to the first 'activation' of the drawable, eg. call to glXMakeCurrent(), in that function, my driver (nvidia closed source) adds a valid GLXFBConfig to the drawable and after that, describeDrawable() prints the correct IDs. The variable 'draw_vis_id' should not be used in any checks, because it may contain an incorrect VISUAL_ID.
Doesn't seem to work, at least not for the applications I tried. Just tested Iconoclast by ASD [1] and Don't Stop by Portal Process [2], same results (BadMatch, X_GLXCreateGLXPixmap).
The BadMatch in X_GLXCreateGLXPixmap is another problem.. here you should get a BadMatch in X_GLXMakeCurrent.
BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a patch but it was rejected. Despite the recent x11drv rewrite (or was it only the windowing code), the OpenGL handling seems very buggy :(
Maybe I should resend the describeDrawable() patch. Don't know why it was rejected.
tom