Lets make a SDK 0.4 Linux nagging thread!

Ok, I now had enough of elite: dangerous and would like to get on with work. Can you please release the sdk 0.4 for linux?!

There are not that many vr penguins, so why give the linux sdk high priority. Is that what I hear you say oculus? But consider the following argument :ugeek: for every dk2 penguin there is another windows developer who is still waiting for his dk2 - so the penguin is actually blocking one dk2 from its proper use. So that's two unhappy developers for each unhappy penguin. And then most of the windows buyers are not developers either but bought the dev kit just to play elite: dangerous - trust me, I wandered among these wretched souls for the last two weeks :mrgreen:

Just received an Oculus Hardware survey email. Couldn't find a "it's a terrific paperweight"-option in there. :shock: :lol:

"francoisvdv" wrote:
Just received an Oculus Hardware survey email. Couldn't find a "it's a terrific paperweight"-option in there. :shock: :lol:

To be fair, the 0.3.2 sdk works, without positional tracking, sort of.
I get a weird situation where vsync on makes vsync go off and verse visa, with stuttering with the false "on" option.
Other then that low persistence is working, rotational tracking is working, latency testing is sort of working (same problem as with vsync)

Yeah it's a pretty shitty situation but it's far from useless.

If the "Linux" options in the OS drop down are any indication, they really need to find some more Linux devs. A dozen different variations on Ubuntu, Mint, "Linux 3.10 64 bit" and "Linux 1.11", whatever the hell that is... No RPM based distros at all. God help you if you run any of the " enterprise" distros, nevermind Slackware, Arch, or roll your own. And their ELA basically prohibits binary redistribution (and, of course, that is the only way they provide the runtime) so you won't likely see packagers for any of the above get anywhere near them.

Sigh... Back in the box. I really wanted to do some non-game based work with this on Linux but my doubts are growing exponentially. Made only that much worse by the lack of response from anyone at Oculus.
Upside: at least I won't have to worry about the DK2 lenses which are, currently, not possible to order replacements of and scratch if you look at them wrong :)

"nuclear" wrote:

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.

There's no reason to turn off the other graphics outputs. Just start an X server configured to display on the oculus, then use its $DISPLAY value with the program you want to have utilize that X server. No point in the xrandr to disable your other displays because none of your oculus program's output would be showing up there anyway.

"nuclear" wrote:

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".

Yep. Unless you're a nut and configure your oculus as a *screen* of your main display, in which case it'd probably be DISPLAY=:0.3 or something - but some people wouldn't want to have to configure their window managers to leave the oculus screen alone, and sliding the mouse pointer into the oculus's X screen probably isn't going to play well with the UI guidelines. :-)

"nuclear" wrote:

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.

This would not result in mirroring in most X setups I've seen. You're probably thinking about how laptops with auxilliary display connectors work, which isn't like normal workstations. The A-C-F8 thing is a bit of a quirk of how Linux handles consoles, too, there's no reason to not have the main display and the oculus display simultaneously active, or even multiple oculi. I wouldn't mind handing my oculus program a command line option (assuming I coded one) like "--mirror-left-to :0.0" to have my program open a second X connection back to the main system display and show a left eye view there in a window (or to a second computer somewhere else in the house or something).

Just to be clear, I don't mean to slam the devs... It is just tgat , as others have pointed out, they seem to be non-Linux folks who were asked to port the rather convoluted looking Windows architecture for the SDK to Linux without much knowledge of Linux. X and v4l2 are perfectly designed for this and the sensor support is likely quite simple. But, instead, the Windows design is being ported hook, line, and sinker..

"matus" wrote:
for every dk2 penguin there is another windows developer who is still waiting for his dk2 - so the penguin is actually blocking one dk2 from its proper use.

I'm pretty sure developing VR under linux is "proper use"... or would you have kept such tech away from ID software back when they were developing Doom on the NeXT, because obviously they couldn't be serious if they weren't doing the majority of their development on a Windows box?

A linux driver opens up additional opportunities for the oculus, from being able to run with lower-cost host computers (no OS license fee), to use in a number of military applications and space uses (NASA has ditched Windows in favor of Linux in some areas), to some huge foreign markets where Windows is distrusted. Adding another user/developer community also raises the chance of a killer app - don't forget to thank the unix realm for, oh, the Internet, the WWW, and email (although I miss the spam-free Internet of 1990 still), and the linux SDK lowers the barrier to entry for a number of developers, since linux is extremely open from a development perspective. There is enormous power is being seriously cross-platform.

As thwalker3 points out (that others pointed out), the hardest thing for doing an SDK across platforms is not knowing the ones of interest all well enough to do the abstractions in the right places. Windows devs would have a tough time getting X right at first, since it's radically different in philosophy and has native support for network-transparent graphics that can be accelerated on different host than the one the app is actually running on. Porting the Windows approach directly will just cripple the result (NVIDIA has at least once reduced its Linux OpenGL driver's capability to keep it from being more capable then the Windows version, which is way more ironic), although the result would probably still be usable, it wouldn't be awesome. It doesn't help that some X developers don't really get the X / GLX underlying philosophy all that well either, not grokking the huge boon of network transparency and focussing on just direct rendering on the local computer instead of the bigger picture where local DRI is just an optimization (it's a bit off topic, but something like Display PostScript's remotely-storable procedures would have ROCKED for network-transparent 3D VR). Sigh.

"ElectricMucus" wrote:

To be fair, the 0.3.2 sdk works, without positional tracking, sort of.
I get a weird situation where vsync on makes vsync go off and verse visa, with stuttering with the false "on" option.
Other then that low persistence is working, rotational tracking is working, latency testing is sort of working (same problem as with vsync).

Now I'm curious: Are you using SDK distortion or did you roll your own client distortion?

I ran a few more experiments yesterday using my own projects, @jherico's example Java project (the last 0.3.2 based version), and the Oculus World Demo that comes with SDK 0.3.2. They all suffer from the same issues:

• Random segfaults. Time until crash is about 15 seconds on average, with a large variance.


• The massive drift that I observed with DK1 is also there with DK2.


• Chroma correction seems totally off/exaggerated, which is probably just related to the next issue.


• The biggest issue is that the distortion itself is broken. When using SDK-side distortion, the result in my experiments always look like that (looks like the forum software does not allow image scaling; "view image" required):

It looks like the (virtual) center of the lenses is always rendered exactly at the lower edge of the viewport, and you only see the upper half of the eye textures. I tried to divide the height of rc.Header.RTSize (that you pass to configureRendering) by 2. But this just shrinks the vertical size and the alignment "lens center = lower edge" is still the same.

Anyone else observing these issues? Just to confirm that it's not my system.

@ElectricMucus: Do you have found any solutions to that or just client-side distortion?

Update: Now I see: There are these hacks to repair the distortion. So maybe you are just not referring to the vanilla 0.3.2 SDK...

Yes, the 0.3.x has known issues with the DK2. These issues have been repaired in the Github version of the SDK, but there hasn't been a new release of the 0.3.x Java binaries. My bad. I'll see if I can get this done tonight, but it's a hectic week with PAX Dev and PAX.

Yes I'm using jherico's fork of 0.3.2. (C++) The distortion correction seems fine although I can't get the chromatic aberration correction to work properly. There is some drift which I assumed is because the lack of camera support, IDK.