SDK 0.4.3 linux bugs and issues

[nuclear]

First of all, please oculus, set up a bug tracker or a mailing list, or something that will facilitate a direct path of communicated bugs and isuses without going through this forum.

I'll post a couple of issues I've found so far with my minimal testing of the new SDK:

1. The LibOVR makefile is broken
1.1 the shared library is built with a -soname including the path from the LibOVR directory to wherever the so is placed. So for instance here the soname of the shared library is something like: ./Lib/Linux/Release/x86_64/libovr.so.0 which is clearly wrong
1.2 there is no installation target in the makefile

I've uploaded a quick fix for both these issues here: http://mutantstargoat.com/~nuclear/tmp/libovr_makefile_install.patch

2. OVR_CAPI_GL.h defines the Disp member of ovrGLConfigData with type _XDisplay* which does not exist. There is a struct _XDisplay (notice: not typedefed), and a type Display. So you'll either have to define it as struct _XDisplay* Disp; or the more correct, not using internal implementation-specific types: Display* Disp;
Obviously none of the test programs within oculus are written in C.

3. in CAPI_GL_DistortionRenderer.cpp, function DistortionRenderer::Initialize, if the user didn't set the Disp member of ovrGLConfigData, the SDK attempts to open a new connection to the X server by calling XOpenDisplay(NULL). That is a mistake, because the application might well have connected to a completely different X server instead of whatever the DISPLAY env var says, which is what XOpenDisplay uses when called with a null argument. The correct approach would be to call glXGetCurrentDisplay() instead, and get the exact same connection used by the client program.

I'll post more issues when I find them, but again, please provide a more direct avenue of reporting bugs.

[nuclear]

One more issue I noticed with my so far very limited testing: the makefile should link all libraries used by libovr to the shared library produced. Otherwise the applications will have to know which libraries libovr happens to use and link them manually.

This is not foolproof, as some systems use the ld-gold linker which doesn't follow dependencies of libraries being linked, and even with the original GNU linker, dependencies can't be carried by the static version of the library anyway. But it doesn't hurt.

Ideally you would also provide a pkg-config file (libovr.pc) which will have to be installed in $(PREFIX)/share/pkgconfig, by the install rule of the makefile. pkgconfig files list commandline options required during compilation and linking so that running pkg-config --libs libovr in the application's makefile, will output the commandline needed to link all of libovr's depedencies. This is de-facto standard practice for all UNIX libraries with complicated dependencies, so that the application won't have to know what each librarie's internal dependencies are.

For now I'm maintaining a mercurial repository of the oculus SDK with my changes so far: http://nuclear.mutantstargoat.com/hg/ovr_sdk/ if you clone it and try an "hg diff -r 0:tip" you'll get a patch of all my changes from the original OVR 0.4.3 release.

[jherico]

CMake for the win. 

[nuclear]

"jherico" wrote:
CMake for the win. 

CMake is ok, I've used it some times but I'm not a huge fan; I prefer hand-crafted makefiles. But either way this is not the venue for such an argument 🙂

[gaugeboson]

Issues I've run into:

1) LibOVR causes a segfault in fglrx/Catalyst (AMD's proprietary driver) by incorrectly passing a GLX_FBCONFIG_ID as a GLXFBConfig to glXGetVisualFromFBConfig. I'm guessing that in nVidia's proprietary driver, GLXFBConfigs happen to just be the ID, but the GLX spec makes it fairly clear that you shouldn't assume that. It seems that in AMD's driver a GLXFBConfig is actually a pointer to a struct so you'll get a segfault when glXGetVisualFromFBConfig tries to dereference it. I don't really have any experience working directly with Xlib/GLX, but I've hacked together a modified implementation of SDKWindow::getVisualFromDrawable that seems to work.

bool SDKWindow::getVisualFromDrawable(GLXDrawable drawable, XVisualInfo* vinfoOut)
{
    _XDisplay* display = glXGetCurrentDisplay();

    unsigned int value;
    glXQueryDrawable(display, drawable, GLX_FBCONFIG_ID, &value);
    const int attribs[] = {GLX_FBCONFIG_ID, (int)value, None};
    int screen;
    glXQueryContext(display, glXGetCurrentContext(), GLX_SCREEN, &screen);
    int numEls;
    GLXFBConfig * config = glXChooseFBConfig(display, screen, attribs, &numEls);
    if (numEls)
    {
        XVisualInfo* chosen = glXGetVisualFromFBConfig(display, *config);
        *vinfoOut = *chosen;
        XFree(config);
        return true;
    }
    return false;
}

2) With the above change, the OculusWorld demo doesn't crash, but it seems to a crapshoot as to whether the window ends up on the correct display. Even when it's on the correct display it's not rotated to account for the portrait orientation of the Rift's display. I haven't attempted to work around it by rotating the display using xrandr since I fixed the segfault, but oculusd seemed pretty unhappy when I had tried that before and the README suggests it's a bad idea.

My initial attempts at setting up a separate X11 screen for the Rift have failed so I don't know if that would fix the rotation issue.

[nuclear]

Edit: Never mind, it can actually become a daemon with -d, skip this one.

Another issue: oculusd is not really a daemon.

It would be useful if oculusd was a daemon. One would start it from init as user nobody or a special user oculus or whatever, and it would sit there forever until applications need it (exactly like a windows "service" does). To do this, oculusd must be able to "daemonize" itself, by double-forking when it starts to shed it's controlling terminal. Then an init script can easily be crated to allow it to start during system bootup.

Possible problems: if oculusd needs any X11 stuff, it might be trickier to make it a proper system daemon. On my spacenavd project, I'm solving this issue by running an X11 detection routine using inotify on the X11 socket, to defer any X11-related initialization until after the X server has started running.

[nuclear]

Not strictly linux-specific bug but: SDK distortion renderer leaves its own shader program bound, and as a result fixed function OpenGL programs that don't even touch the shader program state at all, fail to render correctly.

edit: ovrHmd_ConfigureRendering is responsible for the shader program state leak

Other instances of state creep i've found in the previous SDK version was leaving VBOs/IBOs bound, making straight-up client-side vertex array programs fail. Haven't tested if this problem persists in this version of the SDK as well.

[jherico]

"nuclear" wrote:
Other instances of state creep i've found in the previous SDK version was leaving VBOs/IBOs bound, making straight-up client-side vertex array programs fail. Haven't tested if this problem persists in this version of the SDK as well.

Presumably this is why they're using a new shared context within the distortion renderer. Are you seeing state that's moving across that context boundary?

[nuclear]

"jherico" wrote:

"nuclear" wrote:
Other instances of state creep i've found in the previous SDK version was leaving VBOs/IBOs bound, making straight-up client-side vertex array programs fail. Haven't tested if this problem persists in this version of the SDK as well.

Presumably this is why they're using a new shared context within the distortion renderer. Are you seeing state that's moving across that context boundary?

Are they? As I said, I haven't checked if the VBO problem persists with the new SDK, and I haven't looked into the source of LibOVR 0.4.3 yet at all.

My report of the shader program state creep was merely from outside observation: The simple fixed-function example program[1] I've written last month using 0.4.2 failed to draw anything other than the grey-ish framebuffer clear color after updating to 0.4.3, and when I added a glUseProgram(0) after ovrHmd_EndFrame, the problem went away. There are no other calls to glUseProgram anywhere as I wasn't using shaders at all.

[1]: http://nuclear.mutantstargoat.com/hg/oculus2 (mercurial repo)

[nuclear]

Ok, after some more testing, it turns out the shader program state leak is in ovrHmd_ConfigureRendering.