DefaultVisual is incorrect in2.4.0

[cdavis@…]

When I attempt to run a program from Wine that uses DirectX or OpenGL under X11.app 2.4.0, this happens:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  0 ()
  Value in failed request:  0x22
  Serial number of failed request:  515
  Current serial number in output stream:  515

Then the app terminates.

I produced a Wine log and found that this was the last line in the log before X fails:

trace:wgl:wglGetProcAddress func: 'glAccum'

When it receives a request for a non-WGL function, the Wine wglGetProcAddress() just calls glXGetProcAddress() to get the function out of libGL. For some reason, this fails in 2.4.0 when passed an ordinary GL function. This has been a problem as long as there's been a 2.4.0 (even in the alphas and betas).

This does not happen in X11.app prior to 2.4.0. This is very annoying, because the primary reason I even have X11 is so I can run Wine applications. Because of this, I am not upgrading to 2.4.x until this issue is fixed.

I know you probably want a profile of my system, so I've attached one. I've also attached the Wine log I produced.

Any help you can offer would be appreciated. (For that matter, I get the feeling that you'd appreciate any help that I can offer!)

[cdavis@…]

System Profile for my system

[cdavis@…]

Wine Log with +d3d,+wgl from running RA3 under X11 2.4.0

[jeremyhu@…]

1) If this was a problem for the past 5 months that 2.4.0 has been in development, you should've reported it *MUCH* sooner.

2) Nothing has changed in libGL between 2.3.3.2 and 2.4.0_rc1

3) It works for me in all my GLX tests including this simple test case:

(21:55:42 Fri Jul 24 2009 jeremy@yuffie Power Macintosh)
~ $ cat test.c 
#include <stdio.h>
#include <GL/glx.h>

int main() {
	printf("%p\n", glXGetProcAddress((const GLubyte *)"glAccum"));
	return 0;
}

~ $ gcc test.c -lGL -L/usr/X11/lib

~ $ ./a.out 
0x39644

You need to provide more information... Please try the simple test case I have provided.

[cdavis@…]

Funny... I wrote a similar test case, and that works for me, too. Then my analysis must be wrong. All I know right now is that it worked in 2.3.3.2 and it does not work in 2.4.0, and that it fails trying to import a bunch of functions from libGL using glXGetProcAddress().

Now that I think about it, my analysis never really made sense. Why would glXGetProcAddress() make a server call instead of just returning the function pointer directly? But, then again, why would Wine fail after trying to import just one GL function?

Something's definitely wrong here. All I had to do to make Wine fail was run a DirectX app--any DX app at all. (More specifically, any app that uses wined3d to do its rendering would cause Wine to fail.) In any case now, my summary of this bug is now inaccurate.

Something has crossed my mind: Maybe it never gets around to calling glXGetProcAddress()! I noticed in gdi32.wglGetProcAddress() that before it even thinks about calling the display driver (that would be winex11.drv under X11), it creates a DC (so it CAN call the driver). I wonder if THAT is where it's failing.

When winex11 is initializing its device-specific data (in response to a request to create a DC), it makes four X11 calls:

    physDev->gc = XCreateGC( gdi_display, physDev->drawable, 0, NULL );
    XSetGraphicsExposures( gdi_display, physDev->gc, False );
    XSetSubwindowMode( gdi_display, physDev->gc, IncludeInferiors );
    XFlush( gdi_display );

Any one of these calls could be causing this. Or, I could be terribly wrong (again!). If I only knew...

[jeremyhu@…]

Can you put debugging spew in that to see what is going on and figure out how to reproduce the problem in a simplified case?

[cdavis@…]

Nope, can't be CreateDC(). Inspecting the log reveals that the entire call runs to completion. Something else is at work. The log's no help, because the last few lines show the CreateDCA() call cleaning up before returning to the caller (in this case, wglGetProcAddress()).

I don't understand where else this could possibly be, because we've eliminated glXGetProcAddress().

There's something else I noticed. Before attempting to call {{{glXGetProcAddress()}}, winex11 checks if OpenGL support was already initialized. If it wasn't, among other things, it attempts to query information about the GLX implementation. In doing so, it makes the following calls (irrelevant code omitted):

    template.visualid = XVisualIDFromVisual(visual);
    vis = XGetVisualInfo(gdi_display, VisualIDMask, &template, &num);
    if (vis) {
        ...
        ctx = pglXCreateContext(gdi_display, vis, None, GL_TRUE);
        ...
    }

    if (ctx) {
        pglXMakeCurrent(gdi_display, win, ctx);
    } else {
        ...
    }

    WineGLInfo.glVersion = (const char *) pglGetString(GL_VERSION);
    str = (const char *) pglGetString(GL_EXTENSIONS);

    ...

    pglXQueryVersion(gdi_display, &WineGLInfo.glxVersion[0], &WineGLInfo.glxVersion[1]);

    WineGLInfo.glxServerVersion = pglXQueryServerString(gdi_display, screen, GLX_VERSION);
    WineGLInfo.glxServerVendor = pglXQueryServerString(gdi_display, screen, GLX_VENDOR);
    WineGLInfo.glxServerExtensions = pglXQueryServerString(gdi_display, screen, GLX_EXTENSIONS);

    WineGLInfo.glxClientVersion = pglXGetClientString(gdi_display, GLX_VERSION);
    WineGLInfo.glxClientVendor = pglXGetClientString(gdi_display, GLX_VENDOR);
    WineGLInfo.glxClientExtensions = pglXGetClientString(gdi_display, GLX_EXTENSIONS);

    WineGLInfo.glxExtensions = pglXQueryExtensionsString(gdi_display, screen);
    WineGLInfo.glxDirect = pglXIsDirect(gdi_display, ctx);

After this, it's supposed to print some of this information to the console, but it never does. Either GL was already initialized (but then the call to glXGetProcAddress() would succeed, and thus, so would the call to wglGetProcAddress()!), or one of those calls is failing miserably. Again, I could be wrong.

I'm going to attach the log in case that helps. I have to warn you, though: large portions of it are missing due to a bug in Mac OS itself. (The missing sections are just zeros. They show up in vim as ^@ characters.)

[cdavis@…]

Compressed Wine Log with lots of debug spew from running RA3 under X11 2.4.0

[cdavis@…]

Here's a really simple Win32 test program:

#include <d3d9.h>

int main(void) {
    IDirect3D9 *pd3d9 = Direct3DCreate9(D3D_SDK_VERSION);
    if (pd3d9 != NULL) pd3d9->lpVtbl->Release(pd3d9);
    return 0;
}

Just do:

 $ winegcc test.c -ld3d9
 $ ./a.out

and you'll get the X error.

I stepped through the program with a debugger, and I got the error when I got to the point in the snippet above where it called glXCreateContext(). THAT's the problem right there (and now I'm 100% sure I'm right this time). Now the question is, why?

[cdavis@…]

Oh, and feel free to change the summary. Like I said, it doesn't fit the actual problem anymore.

[cdavis@…]

(Crap, I can't edit my comments!)

If this isn't obvious already, you should enter the contents of my test program into a file (like "test.c") before trying to build it. But you probably knew that already.

[cdavis@…]

OK, now I'm going to attach a test program that doesn't need Wine. Save it, and compile and run it like so:

$ gcc glxtest.c -lX11 -lGL
$ ./a.out

You should get the X error when you run this. I based this on Wine's code.

I probably should have attached the first program. Too late now...

[cdavis@…]

Source for test program that demonstrates problem

[jeremyhu@…]

Thanks for debugging this further. Now I have something to work with.

(gdb) print *vinfo
$5 = {
  visual = 0x80bc00, 
  visualid = 34, 
  screen = 0, 
  depth = 24, 
  class = 4, 
  red_mask = 16711680, 
  green_mask = 65280, 
  blue_mask = 255, 
  colormap_size = 256, 
  bits_per_rgb = 8
}
(gdb) n
15			glrc = glXCreateContext(dpy, vinfo, None, GL_TRUE);
(gdb) n
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  0 ()
  Value in failed request:  0x22
  Serial number of failed request:  17
  Current serial number in output stream:  17

Program exited with code 01.

[jeremyhu@…]

Interesting... visual 34 is actually listed in my 224 GLXFBConfigs visuals rather than my 128 GLX Visuals ... so the problem seems to be with the DefaultVisual(dpy, scr)

[jeremyhu@…]

Ok, this should be fixed in git now. Thanks for your help getting a simplified test case!

​http://cgit.freedesktop.org/xorg/xserver/commit/?id=c81595e23b48368dafc054f023c1dd16bbad9494

[jeremyhu@…]

Can you give this build a try: ​http://people.freedesktop.org/~jeremyhu/PR-287/X11.bin.bz2

decompress it and replace /A/U/X11.app/Contents/MacOS/X11.bin with it.

[cdavis@…]

Nope, doesn't do it for me.

(gdb) print *vinfo
$1 = {
  visual = 0x80bc00, 
  visualid = 34, 
  screen = 0, 
  depth = 24, 
  class = 4, 
  red_mask = 16711680, 
  green_mask = 65280, 
  blue_mask = 255, 
  colormap_size = 256, 
  bits_per_rgb = 8
}
(gdb) n
15			glrc = glXCreateContext(dpy, vinfo, None, GL_TRUE);
(gdb) n
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  0 ()
  Value in failed request:  0x22
  Serial number of failed request:  16
  Current serial number in output stream:  16

Program exited with code 01.
(gdb) quit

I'm looking at the output from the glxinfo command, and I noticed that visual 34 isn't listed at all. I'll attach the output so you can see this for yourself.

I should have done this earlier. Ah well. Can't change the past...

[cdavis@…]

Output from glxinfo command

[jeremyhu@…]

What is the output of 'xdpyinfo'? The problem seems to be that the default X11 visual does not have a corresponding GLX visual (it shows up in xdpyinfo but not glxinfo). This is actually "fine" and wine should not be assuming that the default visual supports GLX (report this to winehq.org).

That being said, there is a bug still in our visuals if we have X11 visuals without GLX counterparts.

[jeremyhu@…]

Odd... the fix worked for 1.6.2, but not 1.5.3. Try out:

​http://static.macosforge.org/xquartz/downloads/X11.bin-1.6.2-apple1.bz2

[cdavis@…]

That's odd indeed. It works with the 1.6 server, but not the 1.5. I think I should attach the output from glxinfo and xdpyinfo under the 1.6 server so we can see what's different.

Well, at least the test program worked. I'm going to see now if Wine works with the 1.6.2 server.

[cdavis@…]

Output from xdpyinfo command (under 1.5)

[cdavis@…]

Output from glxinfo command (under 1.6)

[cdavis@…]

Output from xdpyinfo command (under 1.6)

[cdavis@…]

That's much better. I can run my games in Wine once again. Thanks!

But I can't help but think that there's a very good reason you stuck with server 1.5 for the 2.4 series. Is there?

[jeremyhu@…]

1.6 had more problems than 1.5, and I was pressured to get stable quick, so I decided to punt 1.6 in favor of 1.5 to avoid dealing with issues. The need to stabilize 1.5 ended up going away because I decided to just stick with 1.4 (hence the massive backport of changes from 1.5 to 1.4 after 2.3.3 was released), but I decided to stay with 1.5 for 2.4.0.

I've been putting in effort this last week on the 1.6 branch, and it's fairly stable as well, so 1.6 might make its way into 2.4.1

I backported some glx patches from 1.6 into 1.5, and it's now working here. Please try this: ​http://people.freedesktop.org/~jeremyhu/PR-287/X11.bin-2.bz2

[cdavis@…]

Yup, it works now.

Thanks for taking the time to help me out here. I understand that you're very busy with the upcoming 2.4.0 release, and I really appreciate your work.

[jeremyhu@…]

I glad it works and the fix can make it into 2.4.0.

Please report this problem to winehq as well. They should verify that the default visual is a valid GLX visual.