Lets make a SDK 0.4 Linux nagging thread!

Like many others on this thread (and others throughout the forums), I ordered a DK2 back in April (20th for those of you also waiting) based on the numerous entries on the FAQ and website listing "support [for] Windows, Mac OS X, and Linux" and based on the good looking support story for the original development kit. I was terribly excited to see that my finally arrived this week, only to find that I can't actually use it for much of anything because 0.3.2 only provides very minimal support (zero tracking support, either rotational or positional) and 0.4.x is still unreleased for Linux (and I don't even own a Windows license / machine).

While I understand that Windows is the primary development platform for Oculus (it would be nice to see this in the FAQ rather than having to dig through forum posts to find this out) and that you guys are stretched trying to get 0.4.x and the full DK2 support out for launch, it would be helpful if Oculus could at least provide a timeline of when they expect to release the cross-platform support promised on the website and in the FAQ. Better yet, rather than treating OS X and Linux as second class citizens that only get releases a few months after Windows, has Oculus considered opening up some of the platform integration work so that the OpenSource community can help? Or at least hire some more non-Windows developers (I know numerous folks who might be interested in contract or even possibly FTE work)?

Again, like the others on the thread, I'm trying to keep the note positive and really want to be supportive of Oculus as I think the product is terribly interesting and long overdue given the prevelance of inexpensive LCDs and sensors in the market. But without even a timeline (or much response other than "it is coming", it is hard to know whether I should just resell this thing or wait it out...

OK, so I'm now a DK2 owner, and a Linux user, and I find myself stressin' out a little here waiting on the SDK.

If the wait is going to be much longer... might I suggest a stop-gap? Oculus could consider getting some balls -- like maybe from this place or similar: http://www.showmylogo.com/stress-relievers/ball.htm

Imagine how powerful such matte-black stress balls could be if imprinted on one side with the Oculus logo and on the other side with the Linux logo.

At least, if Oculus were to send me something like that, I'd become a strong believer again. Maybe I'm just easy to manipulate in that way. But right now the only evidence I have (that Oculus actually intends to continue support for Linux in the long term) is essentially lip service -- and I crave something even slightly-more tangible.

Plus such schwag could be functional -- a tool to help manage the recurring stress of waiting in line last. :)

Guys, guys there is a branch 0.4.x-linux available on github, I have no Idea if it's functional but at least we can stop bitching. ;)

Note, this branch is a work in progress. It is neither an official Oculus release of support for Linux, nor is it tested at this point.


Oculus SDK
(C) Oculus VR, Inc. 2014. All Rights Reserved.

The latest version of the Oculus SDK is available at http://developer.oculus.com.

Please see the Oculus SDK Overview in the OculusSDK/Doc/ directory for more information.

"ElectricMucus" wrote:
Guys, guys there is a branch 0.4.x-linux available on github, I have no Idea if it's functional but at least we can stop bitching. ;)

That doesn't work at all. It was just an effort on my part to see how much work was involved in getting the SDK to compile on Linux, but without the Runtime (which now handles the hardware and does all the sensor fusion) it's pretty much useless.

I suspected as much :mrgreen:

"ElectricMucus" wrote:

It should be possible for rift applications to run on their own X server, independently of the regular desktop one. This is essentially direct mode, just without direct frame buffer access (if there even is any)

"nuclear" wrote:

This is a brilliant idea. This way "direct to rift" will be as simple as setting the DISPLAY env var correctly. This has to be brought to the attention of anyone working on the GNU/Linux version of the OVR SDK in case they didn't think about it.

"thwalker3" wrote:
Better yet, rather than treating OS X and Linux as second class citizens that only get releases a few months after Windows, has Oculus considered opening up some of the platform integration work so that the OpenSource community can help? Or at least hire some more non-Windows developers (I know numerous folks who might be interested in contract or even possibly FTE work)?

Great thinking everyone. Linux (and X) are actually the perfect platform for supporting weird and wonderful display devices. Therein lies the tragedy of the current development philosophy at Oculus.

Making Windows the primary OS, which is not very good at supporting exotic displays, has led to the non-standard, hacky and unreliable idea of running a pseudo-service simply to make sure video gets to the right device. I hope users of more versatile operating systems do not get saddled with the same flawed approach, because getting video to the Oculus is actually the simplest part of the process. Providing the sensor data is the more vital function of the SDK, and its proprietary nature is the only reason the knowledgeable and determined community haven't already provided us with a complete DK2 Linux SDK.

"creepytennis" wrote:

Great thinking everyone. Linux (and X) are actually the perfect platform for supporting weird and wonderful display devices. Therein lies the tragedy of the current development philosophy at Oculus.

[...] getting video to the Oculus is actually the simplest part of the process.

Looks like I'm really uneducated when it comes the X server, since I actually had a hard time to get the display set up correctly with DK1. My approach was just to try various xrandr settings (or GUI front-ends for xrandr) and I lost a lot of time because:
- The Rift sensors were only visible for the SDK with specific settings (they are not visible in any mirrored configuration or when I try to run 1080p on the Rift)
- Running on JVM/lwjgl, I didn't find a way to specify the display for fullscreen mode. A (imho very fragile) solution was to run windowed, disable window decorations, and move the window to the correct pixel position.

I haven't tried much with DK2, but my first attempt to rotate the display with xrandr also wasn't successful.

The idea of "running a separate X and specify a $DISPLAY variable" sounds pretty much what I was actually looking for, I just have no idea how to do just that in practice. Can anyone give a hint / small example?

I don't mean to hijack this thread, so back on topic: @OVR, a rough ETA of the Linux release would significantly help to plan development...

"bluenote" wrote:

- Running on JVM/lwjgl, I didn't find a way to specify the display for fullscreen mode. A (imho very fragile) solution was to run windowed, disable window decorations, and move the window to the correct pixel position.

The idea of "running a separate X and specify a $DISPLAY variable" sounds pretty much what I was actually looking for, I just have no idea how to do just that in practice. Can anyone give a hint / small example?

Not sure what lwjgl does, but using GLFW3 (Java bindings here: https://github.com/badlogic/jglfw ) you can get a list of all monitors, and while it doesn't present full EDID information (in particular, parsing the vendor id would be all you would need), it does give you a pretty unique physical size which will let you identify the HMD. GLFW3 lets you pass in the monitor to automatically create a full screen window.

Here's my basic pyglfw code for

getting a rift:
https://github.com/lhl/vrdev/blob/master/002-pyopengl/04-pyglfw-screens.py#L148

making a full screen window:
https://github.com/lhl/vrdev/blob/master/002-pyopengl/04-pyglfw-screens.py#L25

"bluenote" wrote:

Looks like I'm really uneducated when it comes the X server, since I actually had a hard time to get the display set up correctly with DK1.

The fault lies at oculus SDK team's side. It's them who are/were uneducated when it comes to the X server, and used a grotesque approach to identify and utilize the DK1's display...

"bluenote" wrote:
My approach was just to try various xrandr settings (or GUI front-ends for xrandr) and I lost a lot of time because:
- The Rift sensors were only visible for the SDK with specific settings (they are not visible in any mirrored configuration or when I try to run 1080p on the Rift)

... because what they did was enumerate all Xinerama-configured screens on the system (strike one, as nobody uses Xinerama for multimonitor configurations since there are much better ways to do that, like XR&R) to find a screen with a 1280x800 resolution (?!), and pass the desktop coordinates of that screen to the user through the SDK. If that exact configuration isn't found, it just panics and declares that there is no rift ...

"bluenote" wrote:
The idea of "running a separate X and specify a $DISPLAY variable" sounds pretty much what I was actually looking for, I just have no idea how to do just that in practice. Can anyone give a hint / small example?

Setting up a separate X server to run on the rift, shouldn't be too hard to achieve. The "traditional" way would be to make an Xorg-rift.conf file of some sort, that identifies the rift's output in the Device section using PCI-IDs. The more "modern" and much more feasible as part of a driver installation process way, would be to make a script which runs an X server and then instructs XR&R on that X server to turn on the rift's HDMI output, and turn off all other graphics outputs.

You could even achieve that right now, without extra software, by starting a second X server: (X :1), and then using the xrandr tool and passing it something of the form: DISPLAY=:1 xrandr --output DVI1 --off --output HDMI1 -s 1920x1080 -r 75 or something similar.

Then, when you want to run ./someprog on the rift, you just do: DISPLAY=:1 ./someprog. Of course the DISPLAY env-var setting can be wrapped with a script called /usr/bin/direct-to-rift, so that you can just run "direct-to-rift ./someprog". If you want mirroring, just switch on your main graphics output too (again with xrandr) and move over to the second X server by hitting alt-ctrl-f8.

Btw, this spawning of multiple X servers to deal with weird display situations is not something new at all. Laptops with dual intel/nvidia graphics cards (nvidia optimus) have a second headless X server running the nvidia driver, you run your programs with a script called optirun which sets this thing up, and the output is then copied to a window running on the intel driver's X server for displaying.

Thanks a lot for the clarification. Let's hope that this long wait means that we will see some improvements in the next release.