Forum Discussion

🚨 This forum is archived and read-only. To submit a forum post, please visit our new Developer Forum. 🚨
bluenote's avatar
bluenote
Explorer
10 years ago

Linux: Run Rift as separate X display

I'm trying to follow this advice from the LINUX_README:


KNOWN ISSUES
* Frame loss on NVidia TwinView setups. Use an independent X screen for an optimal experience.


... but I'm still having issues to set this up. Since there seems to be a known solution to this problem at Oculus, I'm wondering if it is possible to share a bit more information on that? I don't think my issues are caused by an exotic setup -- in fact my specs are pretty average: Ubuntu 14.04, Geforce 670, nvidia driver 331.

What I have tried so far:

I'm currently trying two different approaches. In the first approach, my xorg.conf looks like this (generated mainly by means of nvidia-xconfig / nvidia-settings):


# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings: version 331.20 (buildd@roseapple) Mon Feb 3 15:07:22 UTC 2014

Section "ServerLayout"
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"
# HorizSync source: edid, VertRefresh source: edid
Identifier "Monitor0"
VendorName "Unknown"
ModelName "LG Electronics W2443"
HorizSync 30.0 - 83.0
VertRefresh 56.0 - 75.0
Option "DPMS"
EndSection

Section "Monitor"
# HorizSync source: edid, VertRefresh source: edid
Identifier "Monitor1"
VendorName "Unknown"
ModelName "OVR Rift DK2"
HorizSync 30.0 - 150.0
VertRefresh 56.0 - 77.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce GTX 670"
BusID "PCI:1:0:0"
Screen 0
EndSection

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

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "DFP-0"
Option "metamodes" "DVI-I-1: nvidia-auto-select +0+0"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "Screen"
Identifier "Screen1"
Device "Device1"
Monitor "Monitor1"
DefaultDepth 24
Option "Stereo" "0"
Option "metamodes" "HDMI-0: nvidia-auto-select +0+0 {rotation=left}"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth 24
EndSubSection
EndSection


So the idea here is to have 1 ServerLayout which has 2 Screens. With this configuration I'm launching my projects as follows:


DISPLAY=:0.1 command_to_run


I can confirm that this has much less "frame loss" compared to what I got with NVidia TwinView setups. However, applications are not able to read any keyboard input with this configuration. Mouse input works, as long as I move the mouse over to the Rift screen and programmatically "grab" the cursor. Is there any known trick to send keyboard input to the second screen? I also tested to just run "DISPLAY=:0.1 gnome-terminal", and it is the same: Even if I click on the window on the Rift screen, I cannot type anything. I should note that on the second screen, there is no window manager at all (not quite sure if this is intended behavior or a bug). Am I supposed to run a separate window manager on this screen as well to enable input handling? I tried to run "DISPLAY=:0.1 compiz" on the Rift, but this immediately fails.

The idea of my second approach is not to run two separate screen within one ServerLayout (:0.0 and :0.1), but configure two independent ServerLayouts (= display ids), each with only one screen (i.e. resulting in :0 and :1). This is probably the cleaner solution, since it makes more sense that the Rift and the main desktop have individual display IDs and are not two screen belonging to one desktop. If I understand it correctly, the first occurrence of a ServerLayout in xorg.conf will be used as default desktop, and all others can be started manually by "startx". The modified xorg.conf looks like this:


Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0" 0 0 # only the main screen, no Rift
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

Section "ServerLayout"
Identifier "Rift"
Screen 0 "Screen1" 0 0 # only the Rift, no main screen
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

# the remained is identical to the version above...


What is strange though: The Rift is still enabled after rebooting with this configuration (login screen visible in the Rift). What is worse: I haven't found a way to start anything on the Rift yet. According to the documentation I was expecting this to work:


sudo startx /full/path/to/command -- :1 -layout Rift


However, this freezes my system completely, not even CTRL+ALT+F_ is working. In the corresponding /var/log/Xorg.1.log I at least saw that my command was (correctly) trying to read the "Rift" ServerLayout but later panicked with an error mentioning "device not found".

I'm wondering if anyone has managed to configure the Rift in this way?

I should mention that the approach with "sudo startx" will change the owner of the .Xauthority of the current user to root. This is pretty nasty, since a login in lightdm (the default Ubuntu login manager) will just fail without any error, and it is not possible to login anymore. Login is still possible in a text shell (CTRL+ALT+F1), though. Changing the owner back to the user solves the problem. Took me quite some time to figure this one out...

11 Replies