Lets make a SDK 0.4 Linux nagging thread!

"jherico" wrote:
I'm quite certain that most Linux developers would prefer having the same functionality as Windows and OSX developers have right now than wait a few more months for async timewarp.

Sure, and I'm in that camp as well, I'm a Linux user who switched temporarily to Windows for the DK2.

What I meant is they may not have yet the people to write a Linux kernel module that supports what is currently available for MS Windows (camera, IR leds, direct mode) and that when they get them they'll release asynchronous time warp at the same time.

"Fredz" wrote:
What I meant is they may not have yet the people to write a Linux kernel module that supports what is currently available for MS Windows (camera, IR leds, direct mode) and that when they get them they'll release asynchronous time warp at the same time.

There is no need to write a kernel module. The camera is handled by the uvcvideo driver, the exposure synchronization can be controlled via the UVC extension unit (which exposes the internal I2C bus). The headset is handled by the hidraw driver, and the IR LEDs can be controlled via HID feature reports.

"Fredz" wrote:
What I meant is they may not have yet the people to write a Linux kernel module that supports what is currently available for MS Windows (camera, IR leds, direct mode) and that when they get them they'll release asynchronous time warp at the same time.

The camera is natively supported in Linux. You can access using the standard camera APIs. Control of the LEDs is done over the HID protocol, very similar to how the tracking hardware for both DK1 and DK2 is enabled. You don't need a kernel module in order to enable it. The HID code in the 0.3.x SDK was abstracted, so that knowledge of the OS specific was separated from the code that sent commands to the headset, and since they already had Linux support in 0.2 and 0.3, there's no reason they can't use the same HID code they already have.

In fact, I've just managed to reverse engineer the commands required to enable the LEDs in Linux and captured a video of them from the Rift camera:




Direct HMD mode is obviously a tougher problem, but the fact is it's less critical on Linux than on windows. In Windows, if the display is treated as a monitor (extended mode) then it has to be turned on before apps can access the device, and as a consequence, windows also extends the desktop to the device, which is undesirable. Linux doesn't have this shortcoming. Nor does Linux have the same issues with tying the refresh rate to the primary windows display.

In other words, Linux has everything you need, right now, to reproduce the level of functionality available on OSX. The only thing missing for me to create a functional Linux SDK right now is the software that converts the camera images into a head pose and the sensor fusion software that combines this with the orientation determined from the IMU.

"pH5" wrote:
The camera is handled by the uvcvideo driver, the exposure synchronization can be controlled via the UVC extension unit (which exposes the internal I2C bus).

Ah nice to know, I didn't thought the camera could be supported natively without writing a specific module.

"jherico" wrote:
In fact, I've just managed to reverse engineer the commands required to enable the LEDs in Linux and captured a video of them from the Rift camera

Good job on the IR leds activation, I guess Linux support is closer than ever then.

"jherico" wrote:
Direct HMD mode is obviously a tougher problem

Do you have any idea about how this could be implemented ? From what I understand on Windows they wrote an interceptor for D3D/DXGI, but I don't know if there is such a thing as DXGI on Linux.

As you said you can sync to a specific display on Linux even if it's not primary or doesn't have the lower refresh rates (at least with the NVIDIA binary driver, no idea for AMD GPUs) so there is less a need for a Direct to Rift feature. But it would still be nice to not have anything to configure and for everything to work automagically like on Windows.

"jherico" wrote:
The only thing missing for me to create a functional Linux SDK right now is the software that converts the camera images into a head pose and the sensor fusion software that combines this with the orientation determined from the IMU.

In case you didn't see it already, there is a nice video from Oculus where Dov Katz explains their implementation (starts at 27:05) :




Could be useful, even if a bit overkill to write such a complicated piece of software single-handedly.

So can we expect this by Christmas 2015 or is that too early? :P

How long will we have to wait for Linux support ?
This is not "bleeding edge". This is "bleeding without an edge".

SDK 0.4 on Linux seems to be important for the arrival of WebVR on Linux.
We can live with a buggy/incomplete/improvised sdk 0.4, but we need "something" to move on with our projects.

Can we please get a statement with some specific information on the subject ?
If you don't have an ETA, maybe at least let us know what the problems are, so we don't have to speculate. Or tell us that the Linux support wont happen for X weeks/months/years. Anything that helps us assess the situation and inform our decisions would be appreciated.

Hey guys, I don't think more nagging will make Linux drivers show up faster. OculusVR has been promising drivers for the past 3 months, but I think they're mostly constrained by Linux-capable/enthusiastic resources - all of them have probably been working on the GearVR. My feeling is that a release is ... imminent, but well, it'll be done when it's done.

That being said, thanks to some fine folk (jherico, pH5, okreylos), there's been really good progress on reversing the DK2 and building open-source drivers. As some have mentioned on this thread, it might be nice to have open source drivers even when the official Oculus VR's drivers are released, as I doubt those will be open-source friendly

Most of the low-level HID work is done, so If you're a dev, especially if you have experience w/ computer vision or pose estimation, or if you have the time/energy to write production C++ and do some cat herding, now might be your time to shine.

Drop by the dev thread here: viewtopic.php?f=20&t=15318&start=20#p205195

I would also like updated Linux drivers. I got my DK2 the other day and its use use is 50/50.
SteamVR works in Linux, but no head tracking. I also cannot get the World demo or Config utility to run or install at all.

I boot back to Windows and I can get a few demos to work only if they have a Direct-to-Rift option.
SteamVR for Windows doesnt work, it doesnt output to my rift in Direct mode, and when i switch to Extend mode it doesnt recognize there is a HMD connected at all.

So for Gaming i have to use Linux (nice, but makes me queasy without head tracking), for a few Demos i have to use Windows.... after all this time, i'd have thought they would be further ahead with the software by now.

"sirik" wrote:
after all this time, i'd have thought they would be further ahead with the software by now.

I'm not convinced there was ever a serious plan to release Linux DK2 drivers close to the launch. I'm also not convinced Linux drivers are being worked on now, given that the task of getting from OSX to Linux is relatively simple if you know how the hardware works. Looking at the "money where your mouth is" thread, It seems possible that an open driver will be ready before the official Oculus one, which further suggests Oculus have kicked Linux drivers into the long grass.

I would add that the DK2 is still being advertised by Oculus as Linux compatible, when it clearly isn't.

http://www.oculus.com/dk2/

Will seriously be looking forward to the Linux SDK being released.
Got the kinect2 libfreenect drivers working with ROS, once this comes out FPV immersion will be epic :D
OculusVR our robots/drones are waiting !! :D