Lets make a SDK 0.4 Linux nagging thread!

So what is the official status on SDK 0.4 for Linux?

"SuperTux88" wrote:
0.3.2 + DK2 works here with linux. :) But no positional tracking. :(

Thanks! That's great. I'll give it a go :D

So my DK2 is here, I watched a few cymatic bruce youtube videos and got dizzy after a few minutes. Apart from that the DK2 is a brick, meh. :|

"SuperTux88" wrote:
0.3.2 + DK2 works here with linux. :) But no positional tracking. :(

Hey, thanks again for your help. I have a firmware question.

I've read on this forum that you have to update the DK2's firmware before using it.

a) Does that still apply if you're using your DK2 with SDK 0.3.2 on Linux?

b) Is it actually possible to update the DK2's firmware using SDK 0.3.2 on Linux?

Many, many thanks if anyone knows the answers to these! :)

I think, if it works the firmware is ok, that guess probably as good as any. It's not if there is a known reason of why to update it or a changelog on the firmware afik.

The jherico fork of the SDK seems to work for me, the world demo compiles and runs without errors, although I haven't gotten rotational tracking to work and had to use the "drag the screen over" technique. I used kde's functionality set the screen rotation, so perhaps using Xinerama next would be the right approach. What's left, there is a udev rule in a script for the tracking which I haven't tried yet.

BTW, thanks again jherico for the effort, the cmake setup is damn convenient :D .

"ElectricMucus" wrote:
BTW, thanks again jherico for the effort, the cmake setup is damn convenient :D .

Not as convenient as Java & Maven, but it suffices to keep me from going insane.

I was thinking,

It should be possible for rift applications to run on their own X server, independently of the regular desktop one.
I used to do that for gaming back in the day when quake3 for linux was hot and new. This gave me far more consistent performance and less hassles.

The advantages would be no window manager or compositing to get in the way, no interference with desktop functionality and less risk of resource deadlocks. This is essentially direct mode, just without direct frame buffer access (if there even is any)

"ElectricMucus" wrote:
I was thinking,

It should be possible for rift applications to run on their own X server, independently of the regular desktop one.
I used to do that for gaming back in the day when quake3 for linux was hot and new. This gave me far more consistent performance and less hassles.

The advantages would be no window manager or compositing to get in the way, no interference with desktop functionality and less risk of resource deadlocks. This is essentially direct mode, just without direct frame buffer access (if there even is any)

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.

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

Thanks for the blessings :)

The issue is I have no idea how to contact this person and pointing out things on this forum... However I just created a support request.

Oh BTW I bought a new acer laptop with preinstalled Windows 8.1, and holy cow that's a piece of bloated crap. :o
Anyway VS2010 express here I come. :|

"Ybalrid" wrote:
I mostly work under Linux.
I don't know well Os X, but on Linux, X (graphical server) is a very old system that wasn't designed for multiscreen applications. Sometimes it's capricious.

Deeply incorrect... although perhaps you've been using ATi cards (that would explain a lot). X has supported multiple monitors (including with mismatched graphics cards) and across-the-Internet graphics displays since the 1980s. I have X sprawled across three monitors for my desktop (24" + 30" + 24"), two of which are rotated 90 degrees (the 24"s), as three separate servers so I can pan all of them individually but with united input devices and window manager. It's rock solid. OpenGL works *really* well on X, although the obvious best approach to doing pure 3D is to run a device with no window manager or anything, just the OpenGL master app on an otherwise clientless (or nearly clientless) display.

And, the insane part is that I can run an OpenGL app on a headless server downstairs and render to my workstation upstairs over the local network using OpenGL via GLX commands instead of trying to stream a window feed from a computer that has no windows or any way to make one. Fast? I'm only getting about 20 frames/second, but that's fine for the OpenGL app I use to replicate active X windows (on the workstation) into the 3D app (currently running on the headless server downstairs via SSH) to let me rotate and zoom in on the windows all I want (great for making small, 90-degree rotated *running* videos bigger and right-side up) I can even type at the windows in the magnifier app instead of on the main screen. The best part is that I didn't write my app to work across servers like this - it just *does* (I'm a bit startled myself, tonight is the first time I've tried it this way).

Not designed for multiscreen, my a**! X works even on *no* screen, displaying to some other one... anywhere on Earth, and still picks up 3D acceleration at the workstation. Plays WoW just fine too - on the 30", with that screen's 3x3 virtual desktop still available and both side monitors' to do work in while waiting for something to spawn.

As noted by others earlier - the use of $DISPLAY to target which Oculus you have plugged in as an X display is great. You have several plugged in? - you could just use different $DISPLAY values for each. Or have one VR app target several Oculi on the same computer by using XOpenDIsplay with several different values of $DISPLAY.