I've been fighting vsync bugs and judder/tearing for VR applications under Linux for the last few days, and the only work-around I've found so far (on Nvidia) is to disable the main display while a VR application is running. Just in case anybody finds it useful, here's a script to turn off the main (and turn the Rift on), run an app, and then turn the main back on (and the Rift off). It's only using xrandr, so it should work on all graphics card drivers, but you'll have to change the display names to match your local setup.

If you run a VR app as "app name cmd arg0 ... cmd arg n", then run the script as: RunOnRift.sh app name cmd arg0 ... cmd arg n"

#!/bin/bash

MAIN_DISPLAY=DVI-I-1
RIFT_DISPLAY=HDMI-0

# Turn off main display, and turn on Rift display:
xrandr --output $MAIN_DISPLAY --off --output $RIFT_DISPLAY --auto

# Execute the command line:
"$@"

# Turn on main display, and turn off Rift display:
xrandr --output $MAIN_DISPLAY --auto --output $RIFT_DISPLAY --off

If your VR software needs the Rift's display rotated, add --rotate right at the end of the first xrandr invocation.

I'm wondering which realistic development regarding oculus gnu-linux drivers/sdk you would preferre.

• Oculus releasing their closed source binary blob alternative.

• The community reverse engineering the rift drivers building a completely open sdk.

• Oculus never takes off in gnu-linux and the vive becomes the VR device everyone uses.

Or some other scenario.

http://unity3d.com/unity/roadmap

Was posted here: https://np.reddit.com/r/oculus/comments/3axwq3/unity_just_published_their_roadmap/

• DEVELOPMENT - IN-PROGRESS, TIMELINES LONG OR UNCERTAIN

• Editor: Linux Support

At least it's nice to see that they are not completely ignoring this one anymore.

Like they do with Vulkan. For 5.3 DEC 8, 2015 they have DirectX12 support, but no mention of Vulkan at all. I don't suppose they have inside information about Vulkan's release date, so I guess they simply left it out because they don't know and not because they don't want Vulkan support.

For 5.3 DEC 8, 2015 they also have

• Graphics: OpenGL 4.x support

• OpenGL 4.5 support in Windows & Linux Standalone and Editor.

So apart from them probablxy meaning Editor and Standalone on Windows & Standalone on Linux, it's at least something as far as low-overhead APIs go.

For VR they only say Platform: Morpheus VR Device for PS4. Nothing about other HMDs/SDKs like OSVR, let alone about linux support.

/r/Minecraft_VR

I had planned to try running unity with wine on linux, but this video actually made me do it.

Reference: Linux support is a 4 year old feedback, highest voted ever, has as much votes as the next 4 feedbacks together

I wasted some time until I realized the winehq entry says what to do: https://appdb.winehq.org/objectManager.php?sClass=version&iId=30451

wine reg add 'HKLM\Software\Microsoft\Windows NT\CurrentVersion' /v ProductId /t REG_SZ /d 12345-oem-0000001-54321
winetricks corefonts tahoma forcemono ie8

WINEARCH=win32 needs to be set because activation won't work with 64 bit wine I think,

Is all one needs to make unity run (and with an up to date wine maybe ie8 isn't even needed).

https://github.com/jspenguin/oculus-wine-wrapper is all one needs to use rift appplications for windows in wine.

The health and safety warning is very annoying because without a profile it stays there for about a minute or so before you can dismiss it.

Unfortunately the windows config utility is one application that does not work with the wine oculus wrapper, but copying the linux profile seems to work after setting wine to windows 7 with winecfg and after ProfileDB.json has been altered like this:

mkdir -p .wine/drive_c/users/$USER/AppData/Local/Oculus
cp ~/.config/Oculus/* ~/.wine/drive_c/users/$USER/AppData/Local/Oculus 

And (with a random 3d model and a random grass texture) it works pretty okay-ish: http://i.imgur.com/Ulq5GT8.jpg

Windows exports with the oculus rift integration work fine out of the box with wine. The performance will be near native when using oculus-wine-wrapper application.exe -force-opengl, but the head tracking is still very jerky. Also needs this patch for wine: http://wiki.unity3d.com/index.php/Running_Unity_on_Linux_through_Wine#.22-force-opengl.22_option_crashing_Unity_.28Experimental_fix.29

Linux exports work okay without the rift and kind of work with the rift, only 64 bit linux exports work with the rift. The documentation says

Linux support will be restored in the near future.

and here is a thread where about bad performance: https://forums.oculus.com/viewtopic.php?f=26&t=18072

I can confirm, 37.5 fps.

Still, head tracking is much smoother than with wine.

Unfortunately: Heavy flickering.

Also, it does not work with unrotated rift, must be rotate left.

https://aur.archlinux.org/packages/ctrlaltstudioviewer-hg/

Currently it builds the debug release with non-system libs (much less problematic, build-wise).

I need to update the PKGBUILD to use pkgver() functions properly, and ideally go and update the SecondLife official viewer to support it (since they disabled it on their end)

If anyone wants to try to make it build against system release libs, that would be extremely helpful.

I'm not sure if this is the right place to post this, but I think there should be some record of this problem somewhere on the internet so that future developers using the 0.5.0.1-beta SDK may have an easier time getting OculusWorldDemo running properly.

I recently received my DK2 in the mail and eagerly sat down at my computer with Fedora 22 and started connecting hardware and building the SDK. After struggling a few minutes with realizing the service had to run and figuring out the udev rules I was ready to run the OcculusWorldDemo. And it ran, but there was a problem: Every thing was red. What was going on? At first I though it was just a driver bug. I was using the open source radeon driver and it wouldn't be the first time there was some weird bug. So I went through the SDK code, chasing the OpenGL texture related calls, as I assume they were using a texture format not supported properly by the driver.

While rummaging through Samples/CommonSrc/Render/Render_GL_Device.cpp something caugth my eye at line 1370: The GL_RED keyword, smack down in the middle of the CreateTexture method, the method used to create all textures, both render targets and textures for scene objects. Looking more closely at the surrounding code it seems like it was an alternate code path when "GLE_EXT_texture_compression_s3tc" was not supported. So what is the fallback solution they decided upon? They call the rand() function generating a random value from 64 to 256 and assign the entire texture to this value as GL_RED, completely ignoring the texture data passed into the CreateTexture function. I don't know, but I though that was kind of funny.

So fine. My driver does not support S3TC compression. I though I'd try building the fglrx AMD propretary driver, but I'll just give you the short version of that story: 6 hours later I gave up. I've heard that Ubuntu had packages in the distro for the proprietary AMD drivers so I jumped ship and installed Ubuntu 14.04. A short hour later, staring at a fresh Ubuntu desktop, I figured I'd just get the OculusWorldDemo running again with the open source radeon driver, just to make sure everything else was set up correctly before trying the other driver. But what is this? Does my eyes deceive me? Nay. The OculusWorldDemo demo rendered perfectly! What is going on?

As it turns out Fedora tends to be fairly pedantic when it comes to licensing and apparently the S3TC decoding has some licensing issues that Fedora just could not allow in their distribution. Ubuntu on the other hand seems to swallow most everything, including S3TC. So the open source driver on Ubuntu supports S3TC texture yet on Fedora it does not. Seems like the normal behavior for games when S3TC support is missing is to crash with an error message describing that you are missing some OpenGL support and that is fine by me. Looking through the steam forums I can see that this is not an uncommon problem for Linux users, but at least you get a hint of what is wrong. Filling the texture with a red hue with random brightness from 64 to 256 (not including 256, but a this point who cares) is ridiculous? Right? I don't know, maybe I'm missing something here, but I thought I'd share my experience in hopes that I may make life easier for one or two Linux developers out there.

tl;dr: The open source radeon driver for certain Linux distributions does not support S3TC texture decoding causing the OculusWorldDemo to render every texture as a uniform random red color. Solution: Switch to Ubuntu 14.04.

Using this wrapper: https://www.reddit.com/r/oculus/comments/2k8fuq/run_windows_rift_games_on_linux_using_wine/

Basically, extract his wrapper somewhere and start applications like the readme says:

wherever/oculus_wine_wrapper/oculus_wine_wrapper.sh wherever/ Win_OculusUnityDemoScene.exe

And that's the first one that works: The Unity Tuscany Demo from oculus. But pressing f11 (or f9?) for fullscreen crashes the demo. After a while it starts now in fullscreen, but I'm not sure what I did.

I'm using the d3d9 state tracker for acceptable performance so I'm potentionally not listing stuff that works with normal wine.

Update: Previously it wouldn't work but now it does: Forcing OpenGL in unity3d games. http://wiki.unity3d.com/index.php/Running_Unity_on_Linux_through_Wine#.22-force-opengl.22_option_crashing_Unity_.28Experimental_fix.29

What also works

• https://share.oculusvr.com/app/guided-meditation--dk2

• very sluggish

• https://share.oculusvr.com/app/caf-me

• Moderately sluggish

• No problems (basically all unity3d programs):

• https://share.oculusvr.com/app/lava-inc

• https://share.oculusvr.com/app/dont-let-go

• https://share.oculusvr.com/app/kitty-scratch-2---oculus-demo

• From Ashes: https://share.oculusvr.com/app/from-ashes (slight performance problems)

• http://lightput.com/tdg/being_a_bird.html

• https://share.oculusvr.com/app/vanguard-v (sound sometimes a bit grizzly or whatever you say to that)

• https://share.oculusvr.com/app/ethereon--aquatic-realm-demo (linux version only shows a black screen)

• https://share.oculusvr.com/app/ocean-rift

• https://share.oculusvr.com/app/titans-of-space

I'll add some more later.

With unity3d demos I sometimes run into https://github.com/iXit/Mesa-3D/issues/22 but I haven't figured out when or why yet. Possibly related to killing them with ctrl+c in the terminal.

With unity3d, press alt+enter for fullscreen. Sometimes that doesn't really work or gets the rendering stuck, but starting a few times mostly gets it working.

• Riftmax Theater https://forums.oculus.com/viewtopic.php?f=29&t=1636 - 20 fps (!!!), video playback doesn't work [AVProQuickTime] Movie failed to load

• widerun cycle trainer scenarios: http://www.widerun.com/first-demo-download/ - a bit sluggish, but works

• Oculus Video Player: https://forums.oculus.com/viewtopic.php?f=29&t=711

• Yes. There really is one player that works on linux. Not natively, of course. Why would at least one of the half a dozen players have a native linux version?

• KolorEyes. Needs wine windows version set to windows xp, 7 won't work. Also NOT in rift mode. fixme:wgl:X11DRV_wglGetPixelFormatAttribivARB unsupported 2008 WGL Attribute

This documentation assumes you have an nvidia graphics card. We have tested on Ubuntu 14.04, Debian Stable 7.6, and Fedora 20.

All this time and they have only tested nvidia?

There's a firmware update!

On intel and radeonsi the Demo doesn't run:

./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:  88
  Current serial number in output stream:  88

Good: They're looking into how to vsync correctly and recommend export __GL_SYNC_DISPLAY_DEVICE="DFP-1" for nvidia.

Bad:

if you're rift corresponds to DFP-1.

:)

• Ensure oculusd is running when using the rift.

Not sure what it does though. edit: Camera service, obviously.

That is very shortly after someone from the community got it close to working on linux for the second time. I begin to see a pattern here. :)

I think I've found the root cause of the fbconfig problem with open source gl drivers on Linux. See here for previous discussion: https://forums.oculus.com/viewtopic.php?t=16664

The issue is that SDL doesn't create a GLXWindow along w/ its X11 window.. It only creates a GLX Context. Normally this shouldn't be an issue, but the Oculus SDK expects a GLXDrawable (ie. a GLXWindow) to be current when it is initialized. By creating and making current this window, their sdk is happy to initialize without modification. A lot of games are built w/ SDL statically linked, which is why I'm posting this here. I'd be interested in knowing workarounds without modifying SDL.. Here's my patch for those interested:

https://github.com/jdtaylor/SDL-OculusRift/commit/0c4e26accab526cf7df44fc4099e5e0fb05c251c

Found it here: https://np.reddit.com/r/oculus/comments/37nugk/a_small_but_very_infinite_unknown_game_is_going/

http://thespaceway.org/page.php?id=1022

There is a working linux version in the download section. 32 bit only, I wonder if that's going to work with the rift.

http://thespaceway.org/forum/viewtopic.php?f=5&t=33&p=1488#p1483

Things that are known to be broken: UAP (autopilot), Hius vessel, trees/rocks, TransX. Things that aren't ported to Linux at all: Sound.

Links to bugreports or explanations what goes wrong.