Lets make a SDK 0.4 Linux nagging thread!

Wouldn't it be simpler to make a Linux & OSX compatible SDK ourselves?

Personally I'd just be happy if Oculus would QA the GL distortion rendering code before releasing an SDK, instead of letting the community do it for them.

Sorry, I'm a bit irritable right now.

Yes, even a simplified version where the Rift is still a normal screen would be sufficient for a start. Sadly, I have some applications that can't be ported to Windows :-(

I mostly work under Linux.

Each new "major" release of the SDK, there is a Windows only beta, then the Os X and Linux version come shortly after.

Since I haven't my DK2 yet (I'm probably on the 2nd batch *finger crossed*) I'm not really impatient to get the Linux 0.4 SDK yet... :roll:

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.

I'm glad to wait the developers get something that works properly before shipping it. I'm realy looking forward the "new way" of displaying on the rift under Linux. It's one of the software features I was waiting the most :)

My order went to processing last night but the news of no linux version has tempered my enthousiasm a little... I only use linux so I'll have to wait for the linux SDK :(

"Ybalrid" wrote:
I'm glad to wait the developers get something that works properly before shipping it. I'm realy looking forward the "new way" of displaying on the rift under Linux. It's one of the software features I was waiting the most :)

You're quite the optimist. I'm personally doubting if they'll go as far as supporting the 'non-desktop' display functionality in Linux. Up until 0.3.x they were still relying on Xinerama for screen manipulation, and investing in Linux development isn't likely to get them that much return on their investment. I think it's more likely that we'll see a linux runtime that supports the sensor functionality, but that the rendering to the Rift without having it as an active display won't be in the Linux release feature set.

"jherico" wrote:

"Ybalrid" wrote:
I'm glad to wait the developers get something that works properly before shipping it. I'm realy looking forward the "new way" of displaying on the rift under Linux. It's one of the software features I was waiting the most :)

You're quite the optimist. I'm personally doubting if they'll go as far as supporting the 'non-desktop' display functionality in Linux. Up until 0.3.x they were still relying on Xinerama for screen manipulation, and investing in Linux development isn't likely to get them that much return on their investment. I think it's more likely that we'll see a linux runtime that supports the sensor functionality, but that the rendering to the Rift without having it as an active display won't be in the Linux release feature set.

I think you're right. Although, I would actually welcome a simpler Linux SDK!

All I really want from the SDK is easy access to the sensor data. Functions which help with stereo rendering, distortion, time-warp etc. are also very nice to have. But getting involved with actually piping the display to the Rift's display etc.? That's going to be very difficult to make truly portable, and maybe beyond what I personally think the SDK should try and do.

Although I use Linux at work, I'm too well versed in X.org, but I thought that Xinerama is obsolete (according to Wikipedia) and that xrandr was the way to go? From my limited experience, xrandr seems to provide better information (like which monitor is the "primary" and other info such as being how to knowing bounds of the monitor to center).

I'm curious as the actual latency of the DK2 on Windows compared to Linux. Is the direct access mode only necessary because of Window's DWM possibly causing an extra frame of latency that there is no clear way to turn off? Like I know in Windows 8 you can't disable the compositor anymore and need hardware fullscreen, or direct X flag, or vendor specific OpenGL flags.

I'm hoping in the Linux that this is not the case and that a normal window is as fast as it can be.

But then again, I wonder what will have to happen when Wayland or Mir starts appearing in a few years.

I don't realy know how X.org works realy... So I don't know how it can be done. I'm just saying it will be nice to have.

For the interest, I think if the Rift can works under linux, it means that you can do VR on "Steambox" running Steam OS. It's still an interesting thing for Oculus.

"kokonut" wrote:
Although I use Linux at work, I'm too well versed in X.org, but I thought that Xinerama is obsolete (according to Wikipedia) and that xrandr was the way to go? From my limited experience, xrandr seems to provide better information (like which monitor is the "primary" and other info such as being how to knowing bounds of the monitor to center).

I think the whole X server stuff is somewhat obsolete. But it works and we have nothing better for now. I don't folow the developement of Wayland, but if I remember, the idea was to have a more modern and simple graphical server.

Anyway, the only thing we can do now is to wait to get a 0.4.x version running under Linux...

I hope it will be out before I receive my DK2. I don't mind booting to windows sometimes, but I realy prefer my ArchLinux/KDE environement ^^"

I don't know that there's been 'no official response', Cyber has said 'in-progress' but no timeline given.

We all know that Oculus is resource limited (in meat-space), and Windows will be their main platform so that's were the effort is being put. That said, I'd _really_ welcome the Linux SDK and was disappointed it was not available at the same time as Windows.

Solution? Put what you (Oculus) have up on Git-Hub, it'll be fixed over the weekend.... the terms of the license mean that it's going to be put up there anyhow, might as well make it your own repo.
Simon.

"kokonut" wrote:

but I thought that Xinerama is obsolete (according to Wikipedia) and that xrandr was the way to go?

Brad has already fixed this in his github/copy of the 0.3.2 SDK, Xinerama is just required for one of the demos I believe.
Simon