Participant

oculusd won't run on my Ubuntu 14.04 system

20 replies
8393 views

On my system, oculusd of SDK 0.4.3 won't run properly.

The camera is not always detected.
After the camera is detected and it enters the tracking loop, it exits with a segfault.
The camera is attached and working as can be checked by VLC player for example.

The camera is reported by oculusd with different resolutions from run to run. I guess some setup code is missing from oculusd, and the settings are those that stay left after last use, eg. by VLC.

oculusd is a closed source component, so there is nothing I can do about I guess?

Additional info:

After plugging the camera, dmesg says:


[ 5859.624052] usb 8-1: new full-speed USB device number 3 using uhci_hcd
[ 5859.790082] usb 8-1: not running at top speed; connect to a high speed hub
[ 5859.829090] usb 8-1: New USB device found, idVendor=2833, idProduct=0201
[ 5859.829097] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5859.829103] usb 8-1: Product: Camera DK2
[ 5859.829107] usb 8-1: Manufacturer: Oculus VR,Inc.
[ 5859.838144] uvcvideo: Found UVC 1.00 device Camera DK2 (2833:0201)
[ 5859.840082] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[ 5859.842289] input: Camera DK2 as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/input/input20

oculusd crashes with:


[TrackingManager] Camera (320x240) added: PrintedSerial=215ZZ4042W8G UUID=H1DE49R6N1E2KW008100
Speicherzugriffsfehler (Speicherabzug geschrieben)

gdb backtrace:


#0  0x000000000049e2b9 in ?? ()
#1  0x000000000049e3e9 in ?? ()
#2  0x000000000049fed3 in ?? ()
#3  0x0000000000497f8d in ?? ()
#4  0x0000000000498303 in ?? ()
#5  0x00000000004986e0 in ?? ()
#6  0x000000000044b414 in ?? ()
#7  0x000000000044b462 in OVR::Thread_PthreadStartFn(void*) ()
#8  0x00007ffff79b3182 in start_thread (arg=0x7ffff7f6e700) at pthread_create.c:312
#9  0x00007ffff6445fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Show previous replies

jimbo00000

Up and Coming

OK, here's an info dump:

I notice that /usr/local/bin/RiftConfigUtil offers no option for direct vs. extended mode. The blue light is on all the time when the DK2 is powered on. The test scene(desk with plant on blue bg) works; fairly smooth but I can see tearing near the center of the screen.

Aparently my test program (https://github.com/jimbo00000/RiftSkeleton) doesn't handle portrait orientation correctly, but manually adjusting the screen orientaion to "Rotate Left" it works correctly. I "force" it to Direct Mode; in the last version I would use (caps & ovrHmdCap_ExtendDesktop) to choose Extended mode. This expression now comes back as true.

/usr/local/bin/OculusWorldDemo does not output to the Rift, but the main monitor. Tracking appears to work in it.

Overall, for the 2 apps that work, I would not characterize the experience as smooth. My app is reporting a consistent 104 fps from its internal counter, but I most definitely notice judder. Toggling Sync to VBlank under OpenGL Settings does not seem to impact this. On top of the judder, I think I am noticing less than ideal tracking performance: the horizon seems to lag as I look quickly up and down.

Here are my machine details:
Linux 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
GK106 [GeForce GTX 650 Ti]
AMD Sempron(tm) 140 Processor
NVIDIA driver version 346.47
NV-CONROL version 1.29

I get a lot of this is not running sudo but the app seems to do just as well:


libusb couldn't open USB device /dev/bus/usb/002/003: Permission denied.
libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/001/008: Permission denied.
libusb requires write access to USB device nodes.

I've also seen this:


QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined

On start of RiftConfigUtil:


Error: [From Service] {ERR-017} [HMD] WARNING: LED state change unverified!
Error: [From Service] {ERR-017} [HMD] WARNING: LED state change unverified!
Error: {ERR-017} [HMD] WARNING: LED state change unverified!

Playing around with NVidia X Server settings:
Under X Server XVideo Settings, "Sync to this display device" didn't seem to have an effect. Is this equivalent to the env variable settings from README?


    export __GL_SYNC_DISPLAY_DEVICE="DFP-1"

steaphan

Participant

"jimbo00000" wrote:
I notice that /usr/local/bin/RiftConfigUtil offers no option for direct vs. extended mode.

In Linux, this is managed by X, not by RiftConfigUtil. To get the effect of Direct Mode (and better performance from the nVidia driver), configure your Rift as a separte screen.

"jimbo00000" wrote:
The blue light is on all the time when the DK2 is powered on.

Is this really all the time, or just all the time while RiftConfigUtil is running (which would be expected)?

"jimbo00000" wrote:
The test scene(desk with plant on blue bg) works; fairly smooth but I can see tearing near the center of the screen.

I am guessing you have your Rift set up with your monitor in nVidia's TwinView. There are many problems with TwinView, including the things you mention here. If you set it up as a separate screen, these problems should go away (though, in the present form of the Linux release, you will have to launch RiftConfigUtil on your Rift screen, and then you will need to click the Demo Scene button while the GUI is on the Rift, which is less than ideal).

"jimbo00000" wrote:
Aparently my test program (https://github.com/jimbo00000/RiftSkeleton) doesn't handle portrait orientation correctly, but manually adjusting the screen orientaion to "Rotate Left" it works correctly. I "force" it to Direct Mode; in the last version I would use (caps & ovrHmdCap_ExtendDesktop) to choose Extended mode. This expression now comes back as true.

If you rotate the display, you will be introducing lag from the driver. Ideally, you should keep it in its native orientation. In general, the only thing you should need to change in your code should be the size of the window you are creating. The rest should be unaffected.

"jimbo00000" wrote:
/usr/local/bin/OculusWorldDemo does not output to the Rift, but the main monitor. Tracking appears to work in it.

If you hit F9, it should (otherwise something is very wrong). If you set your Rift up as a separate screen, then you need to launch it on that screen (like: "DISPLAY=:0.1 OculusWorldDemo"), and *then* hit F9.

"jimbo00000" wrote:
Overall, for the 2 apps that work, I would not characterize the experience as smooth. My app is reporting a consistent 104 fps from its internal counter, but I most definitely notice judder. Toggling Sync to VBlank under OpenGL Settings does not seem to impact this. On top of the judder, I think I am noticing less than ideal tracking performance: the horizon seems to lag as I look quickly up and down.

That sounds like TwinView. Try the separate X screen configuration, and let me know if your experience improves.

"jimbo00000" wrote:
I get a lot of this is not running sudo but the app seems to do just as well:


libusb couldn't open USB device /dev/bus/usb/002/003: Permission denied.
libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/001/008: Permission denied.
libusb requires write access to USB device nodes.

Did you install the udev rule file?

"jimbo00000" wrote:
Playing around with NVidia X Server settings:
Under X Server XVideo Settings, "Sync to this display device" didn't seem to have an effect. Is this equivalent to the env variable settings from README?
    export __GL_SYNC_DISPLAY_DEVICE="DFP-1"

No, XVideo and GL are separate subsystems, with separate settings (and separate bugs).

Thanks for the detailed feedback. Please keep it coming. :)

jimbo00000

Up and Coming

In Linux, this is managed by X, not by RiftConfigUtil. To get the effect of Direct Mode (and better performance from the nVidia driver), configure your Rift as a separte screen.

Using the NVIDIA X Server Settings control panel app to set this requires running as root:

sudo nvidia-settings

Doing so puts me in a considerably worse situation: the output rect for the Demo Scene now appears rotated 90 degrees over my main monitor (X Display 0). The Rift display itself is dark. RiftConfigUtil does recognize when the HMD is turned on and off.

The blue light is on when neither ovrd nor RiftConfigUtil are currently running. It is on when the Rift is configured to X Screen 1 and producing no photons, and also on when configured to X Screen 0 and showing the rotated desktop image.

I can't find any documentation relevant to TwinView explicitly on my system - I don't see the string anywhere in the nvidia-settings(aka "NVIDIA X Server Settings") and the nvidia-* tab completions don't list anything with twin in the name. Are there any applicable command-line utilities that could accept precise input or produce relevant output? Is there any log output worth including?

steaphan

Participant

"jimbo00000" wrote:
In Linux, this is managed by X, not by RiftConfigUtil. To get the effect of Direct Mode (and better performance from the nVidia driver), configure your Rift as a separte screen.

Using the NVIDIA X Server Settings control panel app to set this requires running as root:
sudo nvidia-settings
Doing so puts me in a considerably worse situation: the output rect for the Demo Scene now appears rotated 90 degrees over my main monitor (X Display 0). The Rift display itself is dark. RiftConfigUtil does recognize when the HMD is turned on and off.

Believe it or not, this sounds like things were set up exactly right. I am guessing the only problem is that you need to launch programs that use the Rift with the DISPLAY environmental variable pointing to the Rift screen, and not the default screen. Typically, the Rift ends up on display #0, screen #1 (where the default is #0, #0). So, you need to run OculusWorldDemo with DISPLAY set to ":0.1", using a command like:

DISPLAY=:0.1 OculusWorldDemo

...and then hit F9 for it to go to full-screen mode.

The same for RiftConfigUtil (Run it like: "DISPLAY=:0.1 RiftConfigUtil") - but note that in the present form of the Linux runtime, this means that the actual GUI window for RiftConfigUtil will *also* be on the Rift display, which will make it quite annoying to interact with. This is a known limitation with the current version of the Linux Rift support.

"jimbo00000" wrote:
The blue light is on when neither ovrd nor RiftConfigUtil are currently running. It is on when the Rift is configured to X Screen 1 and producing no photons, and also on when configured to X Screen 0 and showing the rotated desktop image.

That is odd. I am really not sure what would cause that. Do you happen to know if it also behaves this way when connected to a different system, or when run in any other OSes?

"jimbo00000" wrote:
I can't find any documentation relevant to TwinView explicitly on my system - I don't see the string anywhere in the nvidia-settings(aka "NVIDIA X Server Settings") and the nvidia-* tab completions don't list anything with twin in the name. Are there any applicable command-line utilities that could accept precise input or produce relevant output? Is there any log output worth including?

From what I have seen, TwinView is the default when the proprietary nVidia driver detects multiple monitors. Once you have set the Rift up as a separate screen, TwinView is automatically disabled.

jimbo00000

Up and Coming

Using DISPLAY=:0.1 to run the RiftConfigUtil and OculusWorldDemo, I am happy to say that they both work and look very smooth! The tracking and display seem absolutely rock solid.

My LED still stays blue, and this is on a DK2 that works normally when connected to 2 different Win7 machines. Turning the Rift on when connected to my Ubuntu machine, the LED is:
- orange for ~500ms
- blue for ~200ms
- orange for ~200ms
- blue.

The OculusWorldDemo does require an F9 press; before that it displays both views squashed horizontally into the right eye FOV. I see the same thing in my RiftSkeleton example, but have been unable to scale the viewport correctly to the window. I tried adding the ovrDistortionCap_LinuxDevFullscreen flag when calling ovrHmd_ConfigureRendering, but it does not seem to have an effect. I've been digging through the source to OculusWorldDemo to find out what happens when pressing F9, but have only found an implementation for RenderDevice::SetFullscreen in Render_GL_Win32_Device.cpp.

The RiftSkeleton App has interchangeable GLFW3, SDL2 and SFML2 backends. GLFW is the only one that will honor the DISPLAY=:0.1 setting, SFML will fail on X_CreateColormap and SDL will silently ignore the setting and create the window on display 0.0.

While GLFW will create the window on the right display, it also loses input focus so I cannot issue keystrokes to the app. Is there a way to instruct the window to retain input focus using GLFW, SDL2 or SFML2? OculusWorldDemo does it just fine.

jimbo00000

Up and Coming

I found the implementation of PlatformCore::SetFullscreen in Linux_Platform.cpp, and I think glfw might do what's needed. Passing glfwGetPrimaryMonitor() as the 4th parameter of glfwCreateWindow puts the window on the right monitor with what appear to be the right dimensions, and input focus comes along as well. The only problem is I'm seeing a pair of barrel-distorted views in each eye, in both the SDK and client distortion paths.

Oddly, glfwGetMonitors is reporting only one monitor, Monitor #0: 1080x948 @ 119Hz Primary.

cybereality

Inspiring

The refresh rate should be 75Hz. If it's running at 120Hz it triggers a double-image, which is likely what you see.

jimbo00000

Up and Coming

I've tried setting the DK2 monitor to auto and manually to 75Hz, but the settings don't seem to stick. Running sudo nvidia-settings, I see it revert back to 1080x948@119Hz after each run of RiftAppSkeleton. Xinerama is turned off, and I just updated to NVIDIA driver version # 346.59. Still seeing the double-image.

I've included a screenshot of nvidia-settings and the contents of /etc/X11/xorg.conf below. Is there something in configuration I'm missing, or is this a shortcoming of glew or (more likely) my program?


# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 346.59  (buildmeister@swio-display-x86-rhel47-04)  Tue Mar 31 14:41:03 PDT 2015

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 346.59  (buildmeister@swio-display-x86-rhel47-04)  Tue Mar 31 14:42:07 PDT 2015

Section "ServerLayout"

# Removed Option "Xinerama" "0"
# Removed Option "Xinerama" "1"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    Screen      1  "Screen1" RightOf "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Westinghouse Digital Electronics LCM-19v7"
    HorizSync       30.0 - 82.0
    VertRefresh     56.0 - 76.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "OVR Rift DK2"
    HorizSync       30.0 - 150.0
    VertRefresh     56.0 - 77.0
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 650 Ti"
    BusID          "PCI:2:0:0"
    Screen          0
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 650 Ti"
    BusID          "PCI:2:0:0"
    Screen          1
EndSection

Section "Screen"

# Removed Option "metamodes" "VGA-0: nvidia-auto-select +0+0"
# Removed Option "metamodes" "VGA-0: 1280x1024_75 +0+0"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "CRT-0"
    Option         "metamodes" "VGA-0: nvidia-auto-select +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Screen"

# Removed Option "metamodes" "HDMI-0: nvidia-auto-select +0+0"
# Removed Option "metamodes" "HDMI-0: 1080x1920_75 +0+0"
# Removed Option "metamodes" "HDMI-0: 1080x1920 +0+0; HDMI-0: 1080x948 +0+0"
# Removed Option "metamodes" "HDMI-0: 1080x1920 +0+0"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "metamodes" "HDMI-0: 1080x1920_75 +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

steaphan

Participant

"jimbo00000" wrote:
I've tried setting the DK2 monitor to auto and manually to 75Hz, but the settings don't seem to stick. Running sudo nvidia-settings, I see it revert back to 1080x948@119Hz after each run of RiftAppSkeleton. Xinerama is turned off, and I just updated to NVIDIA driver version # 346.59. Still seeing the double-image.

From what I can see, your configuration looks good. Your various problems here seem to be coming from GLFW.

"jimbo00000" wrote:
SDL will silently ignore the setting and create the window on display 0.0.

This was a bug in SDL2, which I actually fixed a few months ago. If you get a more recent version of the SDL2 runtime, this should start working. SDL2 is what I use for my own personal tinkering, and it works fine for me. I'd suggest trying to get this method working first, as I know from personal experience (in Debian Testing) that it can be made to work well.

jimbo00000

Up and Coming

I got it working in both GLFW and SDL - the key insight was from John Tsiombikas's code here: http://nuclear.mutantstargoat.com/hg/oc ... ain.c#l226 Swapping the dimensions of the back buffer for a window created with aspect ratio < 1 made everything display correctly.

https://github.com/jimbo00000/RiftSkeleton

I'm not calling ovrHmd_AttachToWindow in the Linux path. I imagine it's not necessary as everything seems to be working well.

The latest Ubuntu package (libsdl2-dev) only picks up v2.0.2 of SDL, and the latest stable source 2.0.3. Both predate your recent fix. You'll need to get the latest source from Mercurial if you want the DISPLAY variable fix for direct mode on Linux: https://www.libsdl.org/hg.php

Thank you steaphan for your feedback and for the SDL fix!

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO