jogl
  1. jogl
  2. JOGL-376

jogl failure under VirtualBox 3.0.0

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: jogl
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: Other

    • Issuezilla Id:
      376

      Description

      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.

        Activity

        Hide
        merscwog added a comment -

        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.

        Show
        merscwog added a comment - 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.
        Hide
        merscwog added a comment -

        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.

        Show
        merscwog added a comment - 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.
        Hide
        sgoethel added a comment -

        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

        Show
        sgoethel added a comment - 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
        Hide
        merscwog added a comment -

        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.

        Show
        merscwog added a comment - 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.
        Hide
        sgoethel added a comment -

        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 ..

        Show
        sgoethel added a comment - 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 ..
        Hide
        merscwog added a comment -

        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)

        Show
        merscwog added a comment - 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)

          People

          • Assignee:
            jogl-issues
            Reporter:
            merscwog
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: