---- 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\ ig(X11GLXGraphicsConfiguration.java:350) at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfiguration.GLXFBConfig2\ GLCapabilities(X11GLXGraphicsConfiguration.java:294) at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\ eGraphicsConfigurationFBConfig(X11GLXGraphicsConfigurationFactory.java:196) at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\ eGraphicsConfigurationStatic(X11GLXGraphicsConfigurationFactory.java:143) at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\ eGraphicsConfiguration(X11GLXGraphicsConfigurationFactory.java:59) at com.sun.opengl.impl.x11.glx.awt.X11AWTGLXGraphicsConfigurationFactor\ y.chooseGraphicsConfiguration(X11AWTGLXGraphicsConfigurationFactory.java:118) at javax.media.opengl.awt.GLCanvas.chooseGraphicsConfiguration(GLCanvas\ .java:700) 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 visualCaveat=None Opaque. 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 available. ---- Additional Comments From merscwog 2009-07-13 14:53:31 ---- It seems that every invocation of GLX.glXGetFBConfigAttrib() returns GLX_BAD_ATTRIBUTE. 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 at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.chooseGraphicsConfigurationXVisual(X11GLXGraphicsConfigurationFactory.java:285) [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 http://kenai.com/projects/jogl/sources/jogl-git/content/src/jogl/classes/com/sun/opengl/impl/x11/glx/X11GLXGraphicsConfigurationFactory.java?rev=88cc61ba1b5bb874ca9b2a172f7dae187f0f3b17 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 GL_VENDOR: null GL_RENDERER: null GL_VERSION: null 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".
Works since until now. http://jogamp.org/git/?p=jogl.git;a=commit;h=bda9e3bc462e5489aa9bc168adda438864e89ed4