New to the forums? Click here to read the "How To" Guide.

Developer? Click here to go to the Developer Forums.

[Solved] GLXBadDrawable under Linux

MalvineousMalvineous Posts: 13
edited August 2015 in Support
Hi all,

My DK2 arrived yesterday and I'm in the process of getting it up and running under Linux. I can get a picture on the Rift without any problem, but I can't get the SDK demos to work - so far only a WebGL example has given me any sort of experience with the Rift.

The SDK (0.4.3) compiles fine, and I can launch oculusd. But as soon as I try to run OculusWorldDemo_x86_64_Release then it gives me an OpenGL error and oculusd also crashes at the same time with an X11 error:
$ ./oculusd
OVR::DeviceManagerThread - running (ThreadId=0x7facb241c700).
OVR::DeviceManager - initialized.
OVR::Linux::HIDDevice - Opened '/dev/hidraw5'
                    Manufacturer:'Oculus VR, Inc.'  Product:'Rift DK2'  Serial#:'H1DE47R6N1E2KZ00M100'
[TrackingManager] Sensor added: PrintedSerial=206PZ304GBK3 UUID=H1DE47R6N1E2KZ00M100
[TrackingManager] Display added: UUID=H1DE47R6N1E2K Driver=0

...nothing until I launch OculusWorldDemo...

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  2 (X_ChangeWindowAttributes)
  Resource id in failed request:  0x3e00002
  Serial number of failed request:  11
  Current serial number in output stream:  11
OculusWorldDemo says:
$ ./OculusWorldDemo_x86_64_Release
X Error of failed request:  GLXBadDrawable
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  29 (X_GLXGetDrawableAttributes)
  Serial number of failed request:  8094
  Current serial number in output stream:  8094
I am guessing my set up is a little unusual, so that's probably what the problem is. I'm using Intel HD (onboard) graphics, and as they are limited to only three outputs, I have had to unplug one of my three screens to connect the Rift. I'm running in Xinerama mode, which (once I have changed the resolution of my HDMI monitor from 1200x1600 portrait to 1920x1080 landscape) means my desktop appears as a single screen with a resolution of 5680x1600. Thus anything wanting to display on the Rift will have to place the window at x,y coordinates 3760,0 so that it appears on the Rift's screen. However I haven't even gotten far enough to have a window displayed at all, let alone try to get it on the right monitor!

I can't find many references to what would cause a GLXBadDrawable error, other than trying to use some OpenGL command that is not supported. But then some people seem to have gotten the Rift working with Intel HD Graphics, so surely that can't be the problem!

Any suggestions where to start looking, or is this set up completely impossible to have working with the Rift? Thanks!


  • A little further investigation reveals the problem lies in OVR_LinuxSDKWindow.cpp:249. Here the call to glXQueryDrawable fails, because the "drawable" parameter is invalid. This parameter was retrieved in CAPU_GL_Util.cpp:806, and appears to be valid.

    Some digging suggests this is actually a Mesa bug that has been around since 2012 that apparently shows itself when direct rendering is used. It only affects cards using Mesa for OpenGL rendering, which would be Intel ones.

    Looks like until this bug is fixed, the Rift won't work under Linux with Intel cards. I might see if I can turn on indirect rendering for the time being, because while that presumably introduces some latency, at least it might actually work!
  • haagchhaagch Posts: 95
    Hiro Protagonist
    There's a thread from me on this too: viewtopic.php?f=20&t=16201

    Maybe you too want to try whether jhericos fork from with the callback branch gives you better results.
  • I'm seeing this on a Dell Laptop with Intel HD Graphics

    Unfortunately it looks like the 'callback' banch does not build at the moment.
    /media/xubuntu/a38f7259-cbe4-4436-a863-81ade5366c8d/OculusSDK/Samples/CommonSrc/Platform/Linux_Platform.cpp: In member function ‘virtual ovrRenderAPIConfig OVR::Render::GL::Linux::RenderDevice::Get_ovrRenderAPIConfig() const’:
    /media/xubuntu/a38f7259-cbe4-4436-a863-81ade5366c8d/OculusSDK/Samples/CommonSrc/Platform/Linux_Platform.cpp:952:13: error: ‘ovrGLConfigData’ has no member named ‘Win’
         cfg.OGL.Win                = Win;
    /media/xubuntu/a38f7259-cbe4-4436-a863-81ade5366c8d/OculusSDK/Samples/CommonSrc/Platform/Linux_Platform.cpp:953:13: error: ‘ovrGLConfigData’ has no member named ‘Disp’
         cfg.OGL.Disp               = Disp;
    Samples/CommonSrc/CMakeFiles/CommonSrc.dir/build.make:261: recipe for target 'Samples/CommonSrc/CMakeFiles/CommonSrc.dir/Platform/Linux_Platform.cpp.o' failed
    make[2]: *** [Samples/CommonSrc/CMakeFiles/CommonSrc.dir/Platform/Linux_Platform.cpp.o] Error 1
    CMakeFiles/Makefile2:227: recipe for target 'Samples/CommonSrc/CMakeFiles/CommonSrc.dir/all' failed
    make[1]: *** [Samples/CommonSrc/CMakeFiles/CommonSrc.dir/all] Error 2
    Makefile:72: recipe for target 'all' failed
    make: *** [all] Error 2
  • haagchhaagch Posts: 95
    Hiro Protagonist
    edited November 2014
    Ah yes, he didn't fix the samples. You have to build with -DOCULUS_BUILD_SAMPLES=0.

    Instead he has a separate project with a sample program that still has several problems for me but at least starts and renders something:
    There's a bug with paths in the release build so you need to make a debug build with -DCMAKE_BUILD_TYPE=DEBUG too.
  • Oh right, glad I'm not the only one with the problem.

    I found you can force indirect mode (thus avoiding the bug with direct mode) by setting the environment variable LIBGL_ALWAYS_INDIRECT=1 before running any programs. While this does fix the GLXBadDrawable error, unfortunately everything that uses the Rift just segfaults instead :-(

    I'll have to try this alternate SDK branch.

    EDIT: No luck. It compiles and doesn't throw GLXBadDrawable, but it still segfaults in the same place as the latest official SDL with LIBGL_ALWAYS_INDIRECT=1
  • haagchhaagch Posts: 95
    Hiro Protagonist
    I can only say that if I check out the oculusriftinaction repository and switch to the callback branch there and compile it, that output/Example_2_4_HelloRift_d runs but throws a lot of opengl errors.
  • How far do you get?
    $ git branch
    * callback
    $ ./output/Example_2_4_HelloRift 
    Compiling shaders/Chapter5.vs
    That's all I get.
  • haagchhaagch Posts: 95
    Hiro Protagonist
    I wrote it confusingly before. OculusRiftInAction has the problem with the release build:
    Here cmake -DCMAKE_BUILD_TYPE=DEBUG is needed.
    Or you run it while being in the resources directory: resources$ ../build/output/Example_2_3_Display_d
  • Ohh sorry now I understand! I ran it from the resources directory and it put an image on the screen, but it's not Rift-compatible unfortunately. This is what I got.

    I'm not sure why it's crammed in the lower-left of the image instead of spreading across the whole 1920x1080 screen! I tried rotating it back to 1080x1920 but no difference. There was no head tracking either but I'm not sure whether that has been implemented yet - I'm guessing not, so that's probably ok.
  • haagchhaagch Posts: 95
    Hiro Protagonist
    That's how far I have looked so far. At least it renders something without crashing and it looks like something that resembles the distortion for the oculus rift.

    The program spits out a lot of opengl errors when I run it, so I made a break point on _mesa_error and got a few backtraces to where they are coming from and posted them here: viewtopic.php?f=20&t=16201#p214224

    I assume that the program will work much better when those are fixed.
  • jdtaylorjdtaylor Posts: 5
    I'm running into this same problem with the latest ATI Radeon Gallium open source driver on Gentoo Linux using example C++,SDL2,glew code from here: ... t-program/

    mesa 10.5.0
    xorg-server 1.17.1
    xf86-video-ati 7.5.0

    Again, this error only occurs for me with the Mesa Gallium ATI driver. No problem with Nvidia and I havn't tried the proprietary ATI fglrx driver. I'm linking against OVR SDK 0.4.4:

    Breakpoint 1, OVR::SDKWindow::getVisualFromDrawable (drawable=48234507,
    vinfoOut=0x7fffffffcc80) at Src/Displays/OVR_Linux_SDKWindow.cpp:254
    254 if (numElems > 0)
    (gdb) bt 1 full
    #0 OVR::SDKWindow::getVisualFromDrawable (drawable=48234507,
    vinfoOut=0x7fffffffcc80) at Src/Displays/OVR_Linux_SDKWindow.cpp:254
    value = 0
    attribs = {32787, 0, 0}
    screen = 0
    numElems = 0
    config = 0x0
    display = 0x6d6040
    (More stack frames follow...)
    (gdb) c
    [From Service] [TrackingManager] Camera (752x480) added: PrintedSerial=216FVN01GJGR UUID=H1DE47R6N1E23X00T100
    [From Service] [TrackedHMD] Entering vision tracking loop
    [From Service] [TrackedHMD] Skipped 4294963576 frames
    Error: [Context] Unable to obtain x11 visual from context
    X Error of failed request: BadValue (integer parameter out of range for operation)
    Major opcode of failed request: 154 (GLX)
    Minor opcode of failed request: 3 (X_GLXCreateContext)

    Value in failed request: 0x0
    Serial number of failed request: 253
    Current serial number in output stream: 253
    [Thread 0x7fffeaa5e700 (LWP 17732) exited]
    [Thread 0x7ffff240d700 (LWP 17731) exited]
    [Thread 0x7ffff7ff6700 (LWP 17730) exited]
    [Inferior 1 (process 17726) exited with code 01]

    The call to glXQueryDrawable for GLX_FBCONFIG_ID always returns an fbconfigID of zero ('value' here) and so this function always fails to return a Visual. For some reason, OculusWorldDemo doesn't have any issues with the same hardware and setup.. OWD isn't using SDL or glew for setup, though, and there's a bit of fbconfig setup code in SDKWindow that it uses which I'm not.

    I managed to "fix" the issue by modifying the Oculus SDK 0.4.4 to not use glXQueryDrawable in OVR::SDKWindow::getVisualFromDrawable:
    bool SDKWindow::getVisualFromDrawable(GLXDrawable drawable, XVisualInfo* vinfoOut)
        struct _XDisplay* display = glXGetCurrentDisplay();
        static int attribs[] =
            GLX_DOUBLEBUFFER, true,
            GLX_RED_SIZE, 1,
            GLX_GREEN_SIZE, 1,
            GLX_BLUE_SIZE, 1,
        int screen;
        glXQueryContext(display, glXGetCurrentContext(), GLX_SCREEN, &screen);
        int numElems;
        GLXFBConfig* config = glXChooseFBConfig(display, screen, attribs, &numElems);
        if (numElems > 0)
            XVisualInfo* chosen = glXGetVisualFromFBConfig(display, *config);
            *vinfoOut = *chosen;
            return true;
        return false;

    While this works for me and lets me to move on for now, it probably isn't proper as I'm new to fbconfig and glx in general. I'm seeing 160 fbconfig's returned from glXChooseFBConfig and I'm only using the first.. so ymmv. :mrgreen:
  • haagchhaagch Posts: 95
    Hiro Protagonist
    So that's nice: A relatively minimal program that allows experimentation what causes this.

    So I tried it and the first thing I needed to do was editing the Makefile:
    1. Adding -std=c11 to CFLAGS for static_assert
    2. Adding libovr include path etc. On archlinux I made a pkg-config file for it: CFLAGS: `pkg-config --cflags libovr`.

    Then I can replicate the X11 error.

    I think there is something wrong with the window, but I don't know much about glx, so I have no idea. Janus VR does the same thing, but it's a big proprietary program, dolphin vr does the same thing, it's open source, but big nonetheless, so it's really good to see this in a small example because if this gets figured out we can actually make good bug reports there.

    A workaround in the sdk is unfortunately not an option for proprietary applications that statically link it.

    If you have a mesa with debug symbols you can break on glXQueryDrawable and see that drawable=121634836 (some "random" number) matches the "xwininfo: Window id: 121634836 "press 'f' to move to the HMD"" which you get with xwininfo -int and then clicking on the newly created window. And attribute is 32787, meaning GLX_FBCONFIG_ID. And ((int[]) attribute)[1] is again the x id of the window, same as the drawable.

    So far all is good, but glXQueryDrawable then returns 0, because in the loop ... 41f99#n389 nothing in the x reply matches our attribute 32787/GLX_FBCONFIG_ID.

    Probably somewhere there is the solution as you say.. ... o.cpp#L168 ... rm.cpp#L95

    edit: why not a full backtrace:
    Error: [Context] Unable to obtain x11 visual from context
    Breakpoint 1, 0x00007ffff6df9760 in _XError () from /usr/lib/
    (gdb) bt full
    #0  0x00007ffff6df9760 in _XError () from /usr/lib/
    No symbol table info available.
    #1  0x00007ffff7b36932 in glXCreateContext (dpy=0x60bcc0, vis=0x1fb1bd0, shareList=0xeab5e0, allowDirect=1) at glxcmds.c:398
            error = {type = 0 '\000', errorCode = 2 '\002', sequenceNumber = 242, resourceID = 0, minorCode = 3, majorCode = 155 '\233', pad1 = 0 '\000', pad3 = 0, pad4 = 15381984, pad5 = 0, pad6 = 33233872, pad7 = 0}
            config = 0x0
            renderType = 32788
            psc = 0x632380
    #2  0x00007ffff6b15b6e in OVR::CAPI::GL::Context::CreateShared (this=0x1fb1bb0, ctx=...) at /home/chris/build/oculus-rift-sdk-jherico-git/src/OculusSDK/LibOVR/Src/CAPI/GL/CAPI_GL_Util.cpp:495
    No locals.
    #3  0x00007ffff6b11b68 in AutoContext (context=..., this=0x7fffffffd400) at /home/chris/build/oculus-rift-sdk-jherico-git/src/OculusSDK/LibOVR/Src/CAPI/GL/CAPI_GL_Util.h:534
    No locals.
    #4  OVR::CAPI::GL::DistortionRenderer::Initialize (this=0x1fb1ad0, apiConfig=<optimized out>) at /home/chris/build/oculus-rift-sdk-jherico-git/src/OculusSDK/LibOVR/Src/CAPI/GL/CAPI_GL_DistortionRenderer.cpp:187
            config = <optimized out>
            autoGLContext = {savedCurrentContext = {initialized = true, ownsContext = false, incarnation = 1, x11Display = 0x60bcc0, x11Drawable = 54525972, systemContext = 0xeab5e0, x11Visual = {visual = 0x0, visualid = 0, screen = 0,
                  depth = 0, c_class = 0, red_mask = 0, green_mask = 0, blue_mask = 0, colormap_size = 0, bits_per_rgb = 0}}, ourContext = @0x1fb1bb0}
    #5  0x00007ffff6b0666c in OVR::CAPI::HMDState::ConfigureRendering (this=0x1fa4410, eyeRenderDescOut=<optimized out>, eyeFovIn=<optimized out>, apiConfig=0x604b80 <glcfg>, distortionCaps=<optimized out>)
        at /home/chris/build/oculus-rift-sdk-jherico-git/src/OculusSDK/LibOVR/Src/CAPI/CAPI_HMDState.cpp:715
            checkScope = {pChecker = 0x1fa51b0}
    #6  0x00000000004021e9 in init () at src/main.c:189
            i = 2
            x = 536805376
            y = 536805376
            flags = 2
    #7  0x0000000000401c8a in main (argc=2, argv=0x7fffffffd6b8) at src/main.c:66
    No locals.
  • The problem can be fixed with a patch to SDL2: ... 0fb05c251c
  • haagchhaagch Posts: 95
    Hiro Protagonist
    Someone at hi-fi said getting the config from glxquerycontext instead of glxquerydrawable should also work. Something like this: ... 4646ba03c6

    Currently janus vr and hi-fi only show completely black, not sure if it is related to this.

    I'll test the SDL patch, thanks.

    edit: janus vr uses opengl with qt5, not SDL, which suffers from the same problem. So does the RiftConfigUtil.

    hi-fi uses OpenGL 4.3 compatibility profile for now which mesa doesn't support, so I may try an older version or wait until they use OpenGL 4.1 core profile.
  • I just tested with glXQueryContext and can confirm that this also works with current ATI Gallium drivers (I swear I tested this before and it failed though). If Oculus ever enables Linux support again, this should be corrected in their SDK.

    From the book 'OpenGL Graphics with the X Window System' pg 9:
    For backwards compatibility with GLX versions 1.2 and earlier, a rendering context can also be used to render into a Window. Thus, a GLXDrawable is the union {GLXWindow, GLXPixmap, GLXPbuffer, Window}. In X, Windows are associated with a Visual. In GLX the definition of Visual has been extended to include the types, quantities and sizes of the ancillary buffers and information indicating whether or not the Visual is double buffered. For backwards compatibility, a GLXPixmap can also be created using a Visual.
  • Thanks haagch, I just sent a pull request to jherico on github:
Sign In or Register to comment.