Lets make a SDK 0.4 Linux nagging thread!

"jherico" wrote:

"creepytennis" wrote:
I'm getting a little anxious sitting on a $350 brick.

I understand your sentiment, although I think it's a little unfair to characterize the device as a brick. You can use it with SDK 0.3.x, just without positional tracking.

That said, I think Oculus is doing itself a disservice by failing to either release the Linux SDK or release the positional tracking code so that someone else can port it to Linux. They've as much as said that they're focused on Windows and Mac because they are bigger potential markets, but I think this ignores the nature of potentially disruptive technologies.

Right now, I don't think anyone has created the 'killer app' for VR, the app that will make people go out and buy a VR headset specifically for that one experience. I also think that when this app eventually does arise, it's probably not going to come from someone playing around with Unity or Unreal. It's going to come from someone creating something that they're passionate about from the ground up, who can't accomplish what they want within the confines of existing systems that weren't built with VR in mind. And I think the pool of Linux developers are a fertile ground for this kind of application.

I really appreciate your great work on the 0.3 series SDK jherico.

The problem for me is that it's not practical to spend time developing around a deprecated SDK which is unable to implement the main innovation of DK2. This was sold to me as a Linux compatible development kit, but it's impossible to do serious Linux development with it.

I haven't unpacked my DK2 because without Linux drivers or a clear statement about the status of the driver source, I don't know whether I'm going to return it. I don't think that's an unreasonable position given the recent conduct of Oculus. So yes, in effect for Linux developers intending to do the kind of innovative, to-the-metal work you describe, it's a brick.

Your feedback has been noted.

Linux is still being worked on but I don't have an ETA at the moment.

"creepytennis" wrote:
The problem for me is that it's not practical to spend time developing around a deprecated SDK which is unable to implement the main innovation of DK2. This was sold to me as a Linux compatible development kit, but it's impossible to do serious Linux development with it.

I understand not wanting to do throw-away work. However, if you're using the C API, the differences between the 0.3.x SDK and the 0.4.x SDK are pretty minimal.

"creepytennis" wrote:
I haven't unpacked my DK2 because without Linux drivers or a clear statement about the status of the driver source, I don't know whether I'm going to return it. I don't think that's an unreasonable position given the recent conduct of Oculus. So yes, in effect for Linux developers intending to do the kind of innovative, to-the-metal work you describe, it's a brick.

I don't know if Oculus is planning on opening up the source of the position tracking, even once the Linux SDK is released. I'd think that if they were planning to do so they would have done it by now.

"jherico" wrote:

I understand not wanting to do throw-away work. However, if you're using the C API, the differences between the 0.3.x SDK and the 0.4.x SDK are pretty minimal.

Thanks. That's really useful to know. I must admit that I'd (foolishly) assumed coding for 0.3.x and 0.4.x were pretty different, given the amount of 0.4.x queries which come up on the board and the frequent bug reports. Knowing that the C API differences are actually minimal is very useful.

Of course it doesn't 100% solve the problem because without positional tracking I'm really not able to explore the potential of the device in the way my field (humanities / heritage academic research) demands.

"jherico" wrote:

I don't know if Oculus is planning on opening up the source of the position tracking, even once the Linux SDK is released. I'd think that if they were planning to do so they would have done it by now.

I think you're probably right, and obviously it's up to me to decide if that's a dealbreaker or not. TBH in my field it probably is. But then I have to decide if Oculus are worth persevering with in the interim until a) They change their policy b) An Open driver stack reaches maturity or c) A better HMD for research appears.

Ah, that is good to know the differences are minimal -- I also foolishly assumed they were large after having read a while back that they broke compatibility. (And of course, I'm now assuming the differences are indeed minor. :) ) I've had a ton of other stuff to do in the meantime, but that was always my reason for not even bothering to look at it whenever I did have the time. Thanks for the info!

"cybereality" wrote:
... still being worked on but I don't have an ETA at the moment.

Where I come from that's often a figure of speech for: "We don't know how to do it, but we are learning as we go." :twisted:

"ElectricMucus" wrote:

"cybereality" wrote:
... still being worked on but I don't have an ETA at the moment.

Where I come from that's often a figure of speech for: "We don't know how to do it, but we are learning as we go." :twisted:

It's pretty absurd that they don't have a release yet, since they've demonstrated with the OSX release that they can do a release without Direct HMD, which is the tricker part. The only other new component required for DK2 in Linux is the positional tracking for the camera. Camera access works in Linux, so I don't get the hold-up.

Maybe they're busy implementing asynchronous time warp for all the platforms and they are still a little bit behind with Linux/OS X considering the recent post from Brian Hook.

"Fredz" wrote:
Maybe they're busy implementing asynchronous time warp for all the platforms and they are still a little bit behind with Linux/OS X considering the recent post from Brian Hook.

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. From a development perspective, there shouldn't be much difference in the API, so it's pointless to deprive linux devs on that basis.

waiting for Linux too. new developer, new kit: disappointed so far...