Bug 376 - jogl failure under VirtualBox 3.0.0
Summary: jogl failure under VirtualBox 3.0.0
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All linux
: P3 normal
Assignee: Sven Gothel
Depends on:
Reported: 2009-07-10 06:24 CEST by Sven Gothel
Modified: 2010-07-06 06:21 CEST (History)
0 users

See Also:
SCM Refs:
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:51:50 CET

---- Reported by merscwog 2009-07-10 06:24:53 ----

Attempting to run jogl under Kubuntu (or ubuntu 64-bit or 32-bit) within
VirtualBox 3.0.0 under Vista 64-bit results in the following stack trace:

OpenGL Warning: XGetVisualInfo returned 0 visuals for 41047640
OpenGL Warning: glXGetFBConfigAttrib for 0x41047640, failed to get XVisualInfo
Exception in thread "main" javax.media.opengl.GLException: glXGetFBConfig(0x801\
1) failed: error code GLX_BAD_ATTRIBUTE
        at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfiguration.glXGetFBConf\
        at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfiguration.GLXFBConfig2\
        at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\
        at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\
        at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\
        at com.sun.opengl.impl.x11.glx.awt.X11AWTGLXGraphicsConfigurationFactor\
        at javax.media.opengl.awt.GLCanvas.chooseGraphicsConfiguration(GLCanvas\
        at javax.media.opengl.awt.GLCanvas.addNotify(GLCanvas.java:393)
        at java.awt.Container.addNotify(Container.java:2578)
        at java.awt.Window.addNotify(Window.java:662)
        at java.awt.Frame.addNotify(Frame.java:470)
        at java.awt.Window.show(Window.java:858)
        at java.awt.Component.show(Component.java:1563)
        at java.awt.Component.setVisible(Component.java:1515)
        at java.awt.Window.setVisible(Window.java:841)
        at demos.gears.Gears.main(Gears.java:51)

This was for the simple Gears demo, but it happens for any demo.  It might be
considered a VirtualBox bug since glxinfo shows that GLX_SGIX_fbconfig is listed
as an extension.

server glx vendor string: Chromium
server glx version string: 1.2 Chromium
server glx extensions:                 
    GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig
client glx vendor string: Chromium                                     
client glx version string: 1.2 Chromium                                
client glx extensions:                                                 
    GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig
GLX version: 1.3                                                       
GLX extensions:                                                        
    GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig

It likely should return a valid value when requesting GLX_RENDER_TYPE (SGI
OpenGL documentation isn't really clear whether it has to or not because the
default is supposed to GLX_RGBA_BIT if not explicitly included as part of an
attribList), but it seems that even if it is not available, as it is not here,
jogl could fall back to assuming GLX_RGBA_BIT.

What's even more strange, is that the rest of the glxinfo shows that it somehow
thinks that rgba is the render type (maybe as the default?).  All 64 are
identical except for the ID so I've only shown the information for the first one
of ID 0x21 using both the table and verbose form.

[glxinfo -t]
64 GLXFBConfigs:
Vis  Vis   Visual Trans  buff lev render DB ste  r   g   b   a  aux dep ste 
accum buffers  MS   MS
 ID Depth   Type  parent size el   type     reo sz  sz  sz  sz  buf th  ncl  r 
 g   b   a  num bufs
0x21  0 TrueColor    0     24  0  rgba   1   0   8   8   8   0   0   16  8   0 
 0   0   0   1   1  

[glxinfo -v]
64 GLX Visuals
Visual ID: 21  depth=24  class=TrueColor
    bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=1
    rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8           
    auxBuffers=0 depthSize=16 stencilSize=8                      
    accum: redSize=16 greenSize=16 blueSize=16 alphaSize=16      
    multiSample=0  multiSampleBuffers=0                          

Since glxgears works fine, I highly suspect that the jogl version would as well
if it didn't halt because it assumed a GLX FBConfig query on GLX_RENDER_TYPE
would return something other than GLX_BAD_ATTRIBUTE.

---- Additional Comments From merscwog 2009-07-12 09:17:48 ----

The LWJGL (Lightweight Java Game Library) variant of Gears works just fine,
running at the same time as glxgears no less.

After digging into the X11GLXGraphicsCnofiguration source it's clear that my
conjecture was pretty close to correct.

291 	sgoethel 	1992 public static GLCapabilities
GLXFBConfig2GLCapabilities(GLProfile glp, long display, long fbcfg, boolean
isMultisampleEnabled) {
292 	sgoethel 	1919 	int[] tmp = new int[1];
293 	  	  	int val;
294 	  	  	val = glXGetFBConfig(display, fbcfg, GLX.GLX_RENDER_TYPE, tmp, 0);
295 	  	  	if (val != GLX.GLX_RGBA_BIT) {
296 	  	  	throw new GLException("Visual does not support RGBA");
297 	  	  	} 

At line 294, short of catching GLException and parsing the getMessage(), there
isn't any way to continue going on.

Unfortunately, glXGetFBConfig wraps the internals so that you cannot discern
easily why a GLException was thrown.  In this case, a GLX_BAD_ATTRIBUTE should
be just fine.  It seems that the cleanest solution might be to create a derived
Exception that holds the actual return value so it can be examined by other
code, such as the above snippet.

There are many subsequent calls to glXGetFBConfig, so there might have to be
others that use a default value when GLX_BAD_ATTRIBUTE is returned.

A better solution might be to modify getXGetFBConfigAttrib to take a default
optional return value when GLX_BAD_ATTRIBUTE would otherwise be thrown.  That
would remove the need for additional try/catch blocks, and quite clear at any
assumptions that are being made when explicit FGConfigAttrib values are not

---- Additional Comments From merscwog 2009-07-13 14:53:31 ----

It seems that every invocation of GLX.glXGetFBConfigAttrib() returns

Any changes that I make to use explicit values (culled directly from glxinfo
output, and force a retFBID) just moves the final failure to the following:

OpenGL Warning: XGetVisualInfo returned 0 visuals for 40c35090                 
OpenGL Warning: glXGetFBConfigAttrib for 0x40c35090, failed to get XVisualInfo
[Repeated 63 times with different 0x4c????? numbers]

Exception in thread "main" javax.media.opengl.GLException:
javax.media.nativewindow.NativeWindowException: Unable to select oneof the
provided GLCapabilities
[Line 285 is not quite correct, but it's whether the NativeWindowException is
caught and re-thrown as a GLException]

This is really starting to look like a native library access issue, but it could
still be something very unique to VirtualBox.

At least it is easy to replicate the error.  Unfortunately, I no longer have the
experience nor time necessary to do further lower-level debugging.

---- Additional Comments From sgothel@jausoft.com 2009-07-16 00:12:16 ----

The funny thing is that GLX.glXChooseFBConfigCopied(..) seems to return
something, if it wouldn't, we would fall back to the XVisual based configuration
without the GLX FBConfig way.
The latter is necessary for everythin >= GL3.0 and for PBuffer as well.

X11GLXGraphicsConfigurationFactory.java line 201 
X11GLXGraphicsConfigurationFactory.java line 148 of

So what we could do here is to test this VirtualBox OpenGL 'bug' for GLX 
FBConfig beforehand, and then fall back to the XVisual code rigth away.

Anybody willing to test this ? (I don't use VirtualBox, but Linux/KVM only).

However .. it looks like this is a VirtualBox issue, and I doubt that either 
glxgears nor LWGLJ utilize GLX FBConfig ..
Since all operation on the FBConfig ID failed in your thorough test,
I would say we should catch it's failer as described above as a workaround.
Cheers, Sven

---- Additional Comments From merscwog 2009-07-16 12:28:33 ----

So, I forced it to use only chooseGraphicsConfigurationXVisual() and then
further forced it to use the first XVisualInfo that it received because it was
still failing at:
    chosen = chooser.chooseCapabilities(capabilities, caps, recommendedIndex);

I eventually get a black square not quite centered around a swing panel behind
it and the below debug output.

        requested GLCapabilities[Capabilities[Red: 8, Green: 8, Blue: 8, Alpha:
0, Opaque: true], GL profile: GLProfile[GL2/GL2], DoubleBuffered: true, Stereo:
false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red Accum: 0,
Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false, Num samples:
0, PBuffer-FloatingPointBuffers: false, PBuffer-RenderToTexture: false,
PBuffer-RenderToTextureRectangle: false],
        chosen    GLCapabilities: GLCapabilities[Capabilities[Red: 8, Green: 8,
Blue: 8, Alpha: 8, Opaque: true], GL profile: GLProfile[GL2/GL2],
DoubleBuffered: true, Stereo: true, HardwareAccelerated: true, DepthBits: 16,
StencilBits: 8, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16,
Multisample: false, Num samples: 0, PBuffer-FloatingPointBuffers: false,
PBuffer-RenderToTexture: false, PBuffer-RenderToTextureRectangle: false]
FunctionAvailabilityCache.Version.<init>: java.lang.NullPointerException

What is most odd are the values in the GLProfile since they don't match what
come out of glxinfo.  I have no idea where it is getting the Accum values of 16,
and the stereo of true, among some other differences.  The requested GLProfile
is quite close to the actual values put out by glxinfo.

---- Additional Comments From sgothel@jausoft.com 2009-07-19 18:29:52 ----

Sorry .. but Swing will utilize a PBuffer, 
which itself needs GLX FBConfig. 
I assume plain GLCanvas or the new NEWT works without GLX FBConfig
then .. 

---- Additional Comments From merscwog 2009-07-20 08:01:28 ----

I can get demos.es2.RedSquare to run using NEWT, and using an application that
uses GLCanvas, I can at least get to a black screen without any errors (it's not
fully working due to GL_EXT_texture_compression_s3tc not being exposed by
VirtualBox proxy OpenGL driver (it's clearly available in the underlying driver)

--- Bug imported by sgothel@jausoft.com 2010-03-24 07:51 EDT  ---

This bug was previously known as _bug_ 376 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=376

Bug has invalid status, setting status to "NEW".
   Previous status was "STARTED".

Comment 1 Sven Gothel 2010-07-06 06:21:01 CEST
Works since until now.