Showing results for 
Search instead for 
Did you mean: 

[Solved] GLXBadDrawable under Linux

Level 2
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!

Level 2
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!

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

Level 2
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

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

Level 2
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

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

Level 2
How far do you get?

$ git branch
* callback
$ ./output/Example_2_4_HelloRift
Compiling shaders/Chapter5.vs

That's all I get.

Level 3
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

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