GLX_DRAWABLE_TYPE does not report GLX_WINDOW_BIT -> fixed after 4.2

[sagaki]

In the guest PC, I compiled an attached source (mainly borrow from ​http://www.opengl.org/sdk/docs/man/xhtml/glXIntro.xml ) and ran it. I noticed that glXGetFBConfigAttrib() with GLX_DRAWABLE returns only GLX_PIXMAP_BIT(=0x2).

As the sample source works fine, I suggest GLX_WINDOW_BIT(=0x1) value should also be set in GLX_DRAWABLE attribute if VirtualBox has a qualification.

My environments are follows:
Host PC

Version

VirtualBox 4.0.2

Machine

Windows 7 64-bit with NVIDIA NVS 3100M (Lenovo T410)

Guest PC

Version

Guest additions 4.0.3

OS

Ubuntu 10.10 32-bit (2.6.35-25-generic)

Library

libgl1-mesa-dev 7.9~git20100924-0ubuntu2

server glx version string

1.3 Chromium

[sagaki]

sample application source

[sagaki]

There are three points to use GLX_DRAWABLE_TYPE in the source code, ​glx.c:

• glxGetConfig returns GLX_WINDOW_BIT for GLX_DRAWABLE_TYPE.
• glxChooseFBConfig returns an error if GLX_DRAWABLE_TYPE is not GLX_WINDOW_BIT.
• glxGetFBConfigAttrib returns GLX_PIXMAP_BIT for GLX_DRAWABLE_TYPE.

In my idea, glxGetFBConfigAttrib should return GLX_WINDOW_BIT for GLX_DRAWABLE_TYPE. Or the behaviour does not match with others.

[Leonid Lobachev]

Thanks for your finding, it seems reasonable to add GLX_WINDOW_BIT indeed.

[sagaki]

How about adding this feature in 4.1?

[online2@rich]

Running into this problem only when 3d acceleration is enabled. Win 7 64 bit host. Fedora 15 32 bit guest.

All calls to glfwOpenWindow(800, 600, 0, 0 , 0, 0, 0, 0, GLFW_WINDOW); will fail. glfw is unusable with 3d acceleration in VirtualBox. With 3d acceleration off the call works fine. Ultimately fails in

x11_window.c around line 487 on this call

if( !( getFBConfigAttrib( fbconfigs[i], GLX_DRAWABLE_TYPE ) & GLX_WINDOW_BIT ) )

{

Only consider window GLXFBConfigs continue;

}

[online2@rich]

Replying to online2@rich:

Running into this problem only when 3d acceleration is enabled. Win 7 64 bit host. Fedora 15 32 bit guest.

All calls to glfwOpenWindow(800, 600, 0, 0 , 0, 0, 0, 0, GLFW_WINDOW); will fail. glfw is unusable with 3d acceleration in VirtualBox. With 3d acceleration off the call works fine. Ultimately fails in

x11_window.c around line 487 on this call

if( !( getFBConfigAttrib( fbconfigs[i], GLX_DRAWABLE_TYPE ) & GLX_WINDOW_BIT ) )

{

Only consider window GLXFBConfigs continue;

}

Forgot to say I was running VirtualBox 4.1.6

[Michael Thayer]

Replying to sagaki, but should be relevant to later comment authors too:

There are three points to use GLX_DRAWABLE_TYPE in the source code, ​glx.c:

• glxGetConfig returns GLX_WINDOW_BIT for GLX_DRAWABLE_TYPE.
• glxChooseFBConfig returns an error if GLX_DRAWABLE_TYPE is not GLX_WINDOW_BIT.
• glxGetFBConfigAttrib returns GLX_PIXMAP_BIT for GLX_DRAWABLE_TYPE.

In my idea, glxGetFBConfigAttrib should return GLX_WINDOW_BIT for GLX_DRAWABLE_TYPE. Or the behaviour does not match with others.

Had a quick look at that code, and it seems to me that:

• glxGetConfig() should not handle GLX_DRAWABLE_TYPE at all, based on all manual pages I could find for it.
• glxChooseFBConfig() should check whether the value is one of or both of GLX_PIXMAP_BIT or GLX_WINDOW_BIT, as we seem to implement both glXCreatePixmap() and glXCreateWindow() unconditionally with respect to the FB Config.
• glxGetFBConfigAttrib() should return GLX_PIXMAP_BIT | GLX_WINDOW_BIT based on the above.

[Michael Thayer]

I have committed a fix for this, though not (yet) to 4.2, as I cannot be sure this won't break anything.

[Frank Mehnert]

This fix is contained in VBox 4.3 Beta 2, please give it a try.

[sag.aki]

Thanks. glxGetFBConfigAttrib works fine on VBox 4.3 Beta 3.

I'm not sure about glxGetConfig and glxChooseFBConfig, but my target application isn't affected these issues.

[misha]

Thanks for the feedback. VBox 4.3 is released now. Please re-open if the issue persists there.