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.

[mpeers]

"nuclear" wrote:
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..

Are you sure about that? When you run "oculusd --help" you get:
Usage: ./oculusd [options]
Options:
-h | --help Print this message
-p | --pid Location of PID file
-d | --daemonize Daemonize

Have you tried using the command line argument to daemonize it, and are having an issue with it, or did you not realise that the argument was needed?

[jherico]

"nuclear" wrote:
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.

Yes. Actually most of the Linux issues seem to stem from difficulty in creating the shared context correctly. But once they get it working, there shouldn't be any more issues of state creep.

[nuclear]

"mpeers" wrote:

"nuclear" wrote:
Another issue: oculusd is not really a daemon.

Are you sure about that? When you run "oculusd --help" you get:
Usage: ./oculusd [options]
Options:
-h | --help Print this message
-p | --pid Location of PID file
-d | --daemonize Daemonize

Have you tried using the command line argument to daemonize it, and are having an issue with it, or did you not realise that the argument was needed?

Ah! right, I missed that completeley. Usually it's the other way around. Daemons usually become daemons by default and avoid daemonization with a -d argument. Thanks for pointing it out, we can cross this one off the list then 🙂

[infernix]

"gaugeboson" wrote:
... I've hacked together a modified implementation of SDKWindow::getVisualFromDrawable that seems to work.

Thanks, seems to work here too. I too am getting segfaults on Debian Sid, fglrx driver package version 1:14.9+ga14.201-1. Your patch solves that for now.

"gaugeboson" wrote:
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.

This actually appears to work without issue for me with the demo:

xrandr --output DFP9 -s 1080x1920 --pos 2560x0 --rotate left

I do have to manually send the window to the oculus screen but my window manager (awesomewm) requires me to do so anyway.

However, the RiftConfigUtil is very unhappy and returns "Error: Please do not rotate your rift's screen.", then segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5e41338 in glXGetVisualFromFBConfigSGIX () from /usr/lib/x86_64-linux-gnu/libGL.so.1
(gdb) bt
#0  0x00007ffff5e41338 in glXGetVisualFromFBConfigSGIX () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#1  0x000000000041ccc2 in ?? ()
#2  0x00000000004968ac in ?? ()
#3  0x00000000004d06fd in ?? ()
#4  0x00000000004904ab in ?? ()
#5  0x0000000000435c96 in ?? ()
#6  0x0000000000440409 in ?? ()
#7  0x0000000000441803 in ?? ()
#8  0x00000000004269a2 in ?? ()
#9  0x0000000000458732 in ?? ()
#10 0x00007ffff6184658 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#11 0x00007ffff6ce9972 in QAbstractButton::clicked(bool) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x00007ffff6a4e643 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x00007ffff6a4f7b3 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#14 0x00007ffff6a4f89c in QAbstractButton::mouseReleaseEvent(QMouseEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#15 0x00007ffff66efcca in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#16 0x00007ffff66a06cc in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#17 0x00007ffff66a6e7d in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#18 0x00007ffff61703cd in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#19 0x00007ffff66a6633 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#20 0x00007ffff671830b in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#21 0x00007ffff6716d7c in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
---Type <return> to continue, or q <return> to quit---
#22 0x00007ffff673e6c2 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#23 0x00007ffff3e1cc5d in g_main_dispatch (context=0x76c890)
    at /build/glib2.0-dt6trg/glib2.0-2.42.0/./glib/gmain.c:3111
#24 g_main_context_dispatch (context=context@entry=0x76c890)
    at /build/glib2.0-dt6trg/glib2.0-2.42.0/./glib/gmain.c:3710
#25 0x00007ffff3e1cf48 in g_main_context_iterate (context=context@entry=0x76c890, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/glib2.0-dt6trg/glib2.0-2.42.0/./glib/gmain.c:3781
#26 0x00007ffff3e1cffc in g_main_context_iteration (context=0x76c890, may_block=1)
    at /build/glib2.0-dt6trg/glib2.0-2.42.0/./glib/gmain.c:3842
#27 0x00007ffff619d615 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#28 0x00007ffff673e776 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#29 0x00007ffff616ef9f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#30 0x00007ffff616f295 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#31 0x0000000000429a29 in ?? ()
#32 0x000000000045b881 in ?? ()
#33 0x000000000041b9bc in ?? ()
#34 0x00007ffff503bb45 in __libc_start_main (main=0x41b8b0, argc=1, argv=0x7fffffffe2e8, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2d8)
    at libc-start.c:287
#35 0x000000000041c349 in ?? ()
#36 0x00007fffffffe2d8 in ?? ()
#37 0x000000000000001c in ?? ()
#38 0x0000000000000001 in ?? ()
#39 0x00007fffffffe579 in ?? ()
#40 0x0000000000000000 in ?? ()
(gdb) 

A similar patch is likely required.

"gaugeboson" wrote:
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.

AFAIK that would require you to use a secondary video card and start an X server that's only connected to that, because you can only have one FGLRX driver instance bind to one PCIe card. I do have an onboard Intel GPU so I could in theory do this, but it's too much trouble for me. Best to try and fix these issues instead.

[rjoyce]

"infernix" wrote:

AFAIK that would require you to use a secondary video card and start an X server that's only connected to that, because you can only have one FGLRX driver instance bind to one PCIe card. I do have an onboard Intel GPU so I could in theory do this, but it's too much trouble for me. Best to try and fix these issues instead.

Really? You can have two 3d accelerated X screens (as many as there are video outputs actually) on my nvidia using the nvidia driver. I'm not doubting you as we are talking different architectures and drivers, and I'm only familiar with nvidia. I was just surprised.

[infernix]

You can have that under one X server instance, but not two separate X servers. Desktop mirroring, extension and Xinerama works fine in that case, but you can't start an additional X server that addresses the other output on the same card.

Unless there is some other way of running two X servers that I'm not aware of.