Up and Coming

Linux/DK2 Development/Bring-Up Guide?

10 replies
4212 views

I've been following along w/ the Linux nag thread, but is anyone actually doing dev w/ the DK2 on Linux at the moment w/ a version of the 0.3.x SDK? I finally got my DK2 in my hands today and am getting started setting up now.

I'm actually waiting on a HDMI-miniHDMI adapter at the moment in case it makes a difference but I'm attaching it at the moment w/ a mini-DP adapter. I updated the firmware to 2.11 on my Mac.

I'm running a Gigabyte BRIX Gaming (GK104, basically an 870m w/ 2 mini-HDMI and 1 miniDP output). I have one display on HDMI, and when I plug in the DK2 it shows up as an extra display, all I need to do is rotate it counterclockwise for it to display the extended desktop. I am running on a clean Ubuntu 14.04.1 LTS setup w/ the the latest edgers nvidia package (nvidia-343) w/ an out-of-the-box Unity desktop .

I've downloaded the 0.3.2 SDK and it seems to somewhat work. The Configuration Utility runs for a 10 seconds or so before it dies:


*** SensorFusion Startup: TimeSeconds = 1408639842.170932
OVR::DeviceManagerThread - running (ThreadId=0x7f7743438700).
OVR::DeviceManager - initialized.
OVR::Linux::HIDDevice - Opened '/dev/hidraw5'
                    Manufacturer:'Oculus VR, Inc.'  Product:'Rift DK2'  Serial#:'MSCE4BR6K9DA3M00V100'
Error: Magnetometer calibration not found!

Timestamp 0 rollover, was: 2783083885, now: 2780368853
./OculusConfigurationUtility.sh: line 27: 16214 Segmentation fault      (core dumped) ./Tools/OculusConfigUtil/OculusConfigUtil_x86_64

OculusWorldDemo from the Official 0.3.2 runs very briefly before also segfaulting.

I've also checked out @jherico's fork https://github.com/jherico/OculusSDK but haven't gotten either the stable or the 0.3.3.pre1 branch working - is there something I'm missing w/ cmake config? I don't do much C/C++ programming - my plan is actually to try to get to Python as quickly as possible.

In that regard I've also installed @jehrico's python-ovrsdk (master) https://github.com/jherico/python-ovrsdk
It seems to do a bit of a dance on setup but then seems to output (non-positional) tracking ok:


OVR::DeviceManagerThread - running (ThreadId=0x7fede53ad700).
OVR::DeviceManager - initialized.
Segmentation fault (core dumped)
lhl@ono1:~/vrdev/001-pythonsdk$ ./demo.py 
OVR::DeviceManagerThread - running (ThreadId=0x7fbfd472c700).
OVR::DeviceManager - initialized.
OVR::Linux::HIDDevice - Opened '/dev/hidraw5'
                    Manufacturer:'Oculus VR, Inc.'  Product:'Rift DK2'  Serial#:'MSCE4BR6K9DA3M00V100'
Error: Magnetometer calibration not found!

*** SensorFusion Startup: TimeSeconds = 1408640467.836481
OVR::SensorDevice - Closed '/dev/hidraw5'
OVR::Linux::HIDDevice - HID Device Closed '/dev/hidraw5'
OVR::Linux::HIDDevice - HIDShutdown '/dev/hidraw5'
OVR::Linux::HIDDevice - Opened '/dev/hidraw5'
                    Manufacturer:'Oculus VR, Inc.'  Product:'Rift DK2'  Serial#:'MSCE4BR6K9DA3M00V100'
Error: Magnetometer calibration not found!

OVR::SensorDevice - Closed '/dev/hidraw5'
Oculus Rift DK2
OVR::Linux::HIDDevice - HID Device Closed '/dev/hidraw5'
OVR::Linux::HIDDevice - HIDShutdown '/dev/hidraw5'
OVR::Linux::HIDDevice - Opened '/dev/hidraw5'
                    Manufacturer:'Oculus VR, Inc.'  Product:'Rift DK2'  Serial#:'MSCE4BR6K9DA3M00V100'
Error: Magnetometer calibration not found!

Sensor created.
  1.000000     0.000000     0.000000     0.000000
  0.996810     0.018656    -0.000648     0.077604
  0.996828     0.018819    -0.001301     0.077318
  0.996845     0.018971    -0.001954     0.077044
  0.996862     0.019122    -0.002602     0.076769
  0.996879     0.019277    -0.003252     0.076483
  0.996896     0.019439    -0.003909     0.076189
  0.996911     0.019597    -0.004569     0.075914
  0.996926     0.019739    -0.005217     0.075637
  
  ...

This sometimes segfaults but otherwise seems to run indefinitely, w/ somewhat sensical numbers.

OK, so the questions I have:

* The first once is a total noob question: how do I control which display apps render on? For example, the OculusWorldDemo, for all 5-seconds it'll run pops up on my primary display, not the DK2

* If I don't care about the positional tracking atm, what's the best way to get something set up so I'm not constantly segfaulting and I can do some basic dev?

* Are there any good samples around? I have some specific R&D goals (building a 3D WM using the DK2 as my primary display on this Linux system) so plan on going step-by-step, still any existing resources would be pretty useful. Stuff like @jherico's https://github.com/OculusRiftInAction (hey Brad, you're stuff has been super useful, I've ordered the MEAP!)

* I don't see a lot of Linux discussion here. Is there a better forum/IRC channel/other for people that are doing Linux Rift dev?

* Is there an Oculus contact/support/dev who focuses on Linux? Obviously it seems to be the lowest priority at the moment, but just wondering in general how/if people have been able to get problems/issues looked at/fixed? Are there any plans for a Phabricator or something? Obviously this is directed towards Oculus devrel, but it'd be interesting to hear other people's feedback - I played around w/ a DK1, but I'm only now just diving into the weeds doing dev right now...

I'm publishing my work here in case it's useful: https://github.com/lhl/vrdev

My goal, btw, is to get to a usable 3D WM as quickly as possible: https://randomfoo.hackpad.com/3D-Window-Manager-Terminal-vuUkyfPJtv2

lhlAuthor

Up and Coming

Oh, I just saw this from August 2013: https://developer.oculus.com/wiki/Ubuntu_13.04
Most of it appears to be dealing w/ AMD drivers, but I wonder if it'd be best to add a new guide (or maybe a whole Linux page/section). The dev wiki seems pretty bare atm, but seems like it might be the best place to centralize/gather information moving forward?

marcosource

Up and Coming

I'm very interested in this as well.
I'll be ordering a DK2 within the next 2 weeks and I'd like to know if I need to make any major preparations before hand.

marcosource

Up and Coming

I just looked at the project page for your idea, I find it VERY interesting.
With the DK2 it is a lot more feasible than with the DK1 because of the higher resolution.
I have been thinking a lot about something much like it, but have not ever come close to gathering enough information to get to the point you are at now.
I would LOVE to work in that sort of environment!

Keep up the good work!

nuclear

Up and Coming

First of all let me say, my whole rift on linux experience is from DK1 with SDK 0.2.whatever, but I don't think that anything has changed really in later revisions. My DK2 just arrived a couple of days ago, but I didn't bother trying to set it up on linux until the new SDK comes along.

"lhl" wrote:

* The first once is a total noob question: how do I control which display apps render on? For example, the OculusWorldDemo, for all 5-seconds it'll run pops up on my primary display, not the DK2

The SDK gives you the offset at which you need to place your rendering window, so that it falls in the rift's part of the desktop. So all you need to do is just create or move your output window at these coordinates. I have a very simple test program I did with OpenGL/GLUT on linux that starts on a window wherever, then when you press 'f' it goes fullscreen on the rift. Feel free to grab it from my mercurial repo if you think that'll be useful as an example: http://nuclear.mutantstargoat.com/hg/oculus1/
Again it's for LibOVR 0.2.x so ymmv.

"lhl" wrote:

* If I don't care about the positional tracking atm, what's the best way to get something set up so I'm not constantly segfaulting and I can do some basic dev?

If you want to hack stuff right now and you don't care about positional tracking, I'd just give OpenHMD a go. Free software, and I see that they added DK2 support a couple of days ago. Haven't tried it myself, but the API looks *much* more reasonable and well designed than the LibOVR crap, and it doesn't depend on Xinerama to work either: http://openhmd.net/

"lhl" wrote:

* I don't see a lot of Linux discussion here. Is there a better forum/IRC channel/other for people that are doing Linux Rift dev?

If you find or start one, drop us a line. I'd love a linux-specific VR/rift discussion "place". Especially if it's not swamped with unity/unreal/whatever-cookie-cutter-engine crap.

John Tsiombikas webpage - blog - youtube channel

lhlAuthor

Up and Coming

"nuclear" wrote:

"lhl" wrote:

* The first once is a total noob question: how do I control which display apps render on? For example, the OculusWorldDemo, for all 5-seconds it'll run pops up on my primary display, not the DK2

The SDK gives you the offset at which you need to place your rendering window, so that it falls in the rift's part of the desktop. So all you need to do is just create or move your output window at these coordinates. I have a very simple test program I did with OpenGL/GLUT on linux that starts on a window wherever, then when you press 'f' it goes fullscreen on the rift. Feel free to grab it from my mercurial repo if you think that'll be useful as an example: http://nuclear.mutantstargoat.com/hg/oculus1/
Again it's for LibOVR 0.2.x so ymmv.

OK, I was originally checking out GLUT (I remember using that back in the ... 90s but its multi-monitor support looked a bit lackluster. In the end I ended up using GLFW, which is much more modern and is pretty actively developed. There are lots of language bindings as well.

If you can read the EDID, Oculus' manufacturer ID is "OVR" and it is easy to target which monitor. You can get this information parsing xrandr --verbose (read-edid barfed on my system), but I was lazy so I'm just going by physical size that GFLW provides instead, which is probably good enough: https://github.com/lhl/vrdev/blob/master/002-pyopengl/04-pyglfw-screens.py#L38

"nuclear" wrote:

"lhl" wrote:

* If I don't care about the positional tracking atm, what's the best way to get something set up so I'm not constantly segfaulting and I can do some basic dev?

If you want to hack stuff right now and you don't care about positional tracking, I'd just give OpenHMD a go. Free software, and I see that they added DK2 support a couple of days ago. Haven't tried it myself, but the API looks *much* more reasonable and well designed than the LibOVR crap, and it doesn't depend on Xinerama to work either: http://openhmd.net/

Thanks, looks like there's a Python binding as well: https://github.com/lubosz/python-rift

I'll try both and see what's more stable, but if the python bindings for LibOVR don't crash much I'll probably go w/ that.

I'm assuming that while Oculus will build their positional tracking into a Linux lib eventually, it's probably pretty unlikely they'll open source their code, so someone would need to write custom constellation tracking/fusion code into OpenHMD (currently would involve patching libuvc and implementing something like PosiTTron http://www.roadtovr.com/posittron-diy-oculus-rift-positional-tracking-virtual-reality/3/ - I don't think that code was ever open sourced and would have to be adapted to calibrating based on purely and refresh and geometry vs color - who knows, someone may build it, but seems like a bit of wasted effort to be rebuilding all that stuff) .

"nuclear" wrote:

"lhl" wrote:

* I don't see a lot of Linux discussion here. Is there a better forum/IRC channel/other for people that are doing Linux Rift dev?

If you find or start one, drop us a line. I'd love a linux-specific VR/rift discussion "place". Especially if it's not swamped with unity/unreal/whatever-cookie-cutter-engine crap.

It seems like the easiest thing to do would be to simply request a Linux Developer Forum here? Is there any way to get the attention of Oculus devrel/community management?

Otherwise, something like grove or slack (a chat channel w/ logging and search) would be good since it's probably a pretty small community of active devs, but sadly, those services are more oriented for commercial workgroups vs communities of interest (lots of signup, hard to easily drop into).

BTW, I started up a Linux page on the wiki. It's pretty sparse right now, but I think it would be a good starting point for collection sample code, development resources, and common issues people might be running into w/ Linux dev: https://developer.oculus.com/wiki/Linux

nuclear

Up and Coming

"lhl" wrote:

OK, I was originally checking out GLUT (I remember using that back in the ... 90s but its multi-monitor support looked a bit lackluster.

Well, it does allow you to position and resize a window at will, and that's all you need in this case.

"lhl" wrote:

someone would need to write custom constellation tracking/fusion code into OpenHMD (currently would involve patching libuvc and implementing something like PosiTTron http://www.roadtovr.com/posittron-diy-oculus-rift-positional-tracking-virtual-reality/3/ - I don't think that code was ever open sourced and would have to be adapted to calibrating based on purely and refresh and geometry vs color - who knows, someone may build it, but seems like a bit of wasted effort to be rebuilding all that stuff) .

It's definitely *not* wasted effort. Not having to beg oculus for the linux SDK, but rather having a trully free software SDK/driver for the rift is in my opinion extremely worthwhile.

The trackir-like LED tracking algorithm from linuxtrack might be a good starting point: https://code.google.com/p/linux-track/

John Tsiombikas webpage - blog - youtube channel

lhlAuthor

Up and Coming

"nuclear" wrote:

It's definitely *not* wasted effort. Not having to beg oculus for the linux SDK, but rather having a trully free software SDK/driver for the rift is in my opinion extremely worthwhile.

Let me rephrase that. Given that Oculus's stated goals has been to accelerate mass adoption of VR, I'm not exactly sure how the SDK/drivers benefit from being closed source in the first place - especially for a developer kit that'll soon be obsolete.

Reverse engineering the tracking (has anyone measured/determined how the LED signaling works yet even?) is a non-trivial effort, and with such a small dev pool, would certainly be effort that could/would be spent building apps if the specs/drivers were simply published (*ahem*, Oculus).

Even assuming it's done successfully, there's an unknown (non-trivial IMO, but obviously just speculation) chance that CV1's low-level tracking implementation will be substantively different - it'd be a constant cat/mouse game. Now, this is a pretty traditional paradigm w/ shortsighted HW manufacturers and open-source devs, but the Oculus guys seem pretty smart, maybe it'd be easier to try to convince them that this is dumb? I don't think they purposefully want to make their hardware hard to develop on for such an important platform (yes, while Linux is small fries for current gaming, the next generations of VR OS's and dedicated devices is *not* going to be or being built on Windows).

It'd be nice if there was a way to talk to/hear from Oculus devrel - I'm relatively new to these forums, does anyone from Oculus actually interact w/ the devs here or is this a fungus farm type of situation? I'll be heading to Oculus Connect, so I guess I can ask in person about the state of drivers...

Back on a pure technical track, if one is planning on doing dev w/o the SDK (eg like you have to on Linux right now), what's the state of running the distortions for DK2? Does one have to dig the math out of 0.4.x's OVR_Stereo.h or has someone done that already?

mungewell

Up and Coming

"lhl" wrote:

Back on a pure technical track, if one is planning on doing dev w/o the SDK (eg like you have to on Linux right now), what's the state of running the distortions for DK2? Does one have to dig the math out of 0.4.x's OVR_Stereo.h or has someone done that already?

You could look at:
https://github.com/bjornblissing/osgoculusviewer

For DK1 they had the distortion in their code, and it was reported that they've updated for DK2 (although I haven't tried it recently).
Simon

Gypsy816

Up and Coming

The old SDK might not support Linux currently but we're working to implement it in a future update.

Oculus Community Manager - kweh!

vrcoder3d

Participant

My pre-SDK Linux+DK2 experience went a little better than expected -- quarternion tracking "just worked" and seemingly-correct stereoscopic worked too (after getting the monitor layout sorted). It's still a far worse experience than DK1 though, so I think I'll go back to waiting for the Linux DK2 SDK (and back to using my DK1 for development).

In case useful to others -- I'm running Ubuntu 12.04.3 and developing with an arbitrarily-old branch of jherico's OculusSDK (from around mid-June; OVR_VERSION_STRING says it's 0.3.2)

When connecting the DK2 it was immediately recognized as a portrait 1080x1920 display -- which I managed to get into extended-desktop mode (and horizontal) using the following XRandR command-line:

xrandr --output DFP3 -s 1080x1920 --pos 1920x0 --rotate left

(my primary monitor is an HD TV so position 1920x0 is just to its right)

With the DK1 I had been using cloned displays -- but the DK2 (with 0.3.2) seems to work slightly-faster somehow in extended-desktop mode. To get that to work required adding an x-pixel coordinate to my prototype -- which is either used to identify the correct GLFW monitor (at that location, if going full screen) or for positioning the actual GLFW window.

(... didn't even try connecting the tracking camera yet -- planning to wait until official Linux support before messing with that at all)

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO