Added a docker.sh script which builds the driver using the same version of libstdc++ as steamvr!

[hradec]

docker.sh create a docker container with Ubuntu 16.04 and everything needed to build SteamVR-OpenHMD.

This method makes the driver works with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 environment var, which essentially forces Steam to use it's own libraries instead of the system one.

In this case, we must build the driver with the same GCC used to build SteamVR, or else the driver will fail to load! (so the driver can work with steam runtime libstdc++)

More information can be found here: https://github.com/ValveSoftware/steam-for-linux/issues/4475 (search for "STEAM_RUNTIME_PREFER_HOST_LIBRARIES:")

[ChristophHaag]

Cool, someone tries to use this. :)

I've never had such issues on Arch, maybe because I have steam-native-runtime installed, but I'll assume the docker stuff works too.

I'm kinda waiting for OpenHMD to finish positional tracking & controller support for the Vive before finishing up this plugin e.g. performance might be bad unless the pose from OpenHMD is updated in a separate thread, but all contributions are very welcome.

Open source steamvr is most likely not going to happen anytime soon, unless someone is making it themselves. https://github.com/ChristophHaag/openvr_api-libre is a start but there is a lot to implement. Most likely OpenXR will be out and most applications will support OpenXR before it gets useful and at this point OpenHMD will be an OpenXR runtime anyway.

[hradec]

Cool, someone tries to use this. :)

What is cool is that "someone" wrote this, my friend!!! Thank you so very much!! 8)

It's being a bit overwhelming for me to get a simple HMD working on Linux. There's so much scattered information out there that it took me a few weeks to "digest" just a bit to be able to get going. OSVR looks good, but I found it to be very "complex" to setup.. lots of little config files here and there, and not much clear documentation about it (at least for the DK1).

OpenHMD to me seems to be the best of it all because it's simplicity and self-containment. I just love the fact it doesn't need a daemon!!! (which means I can easily run on a small platform like a raspberry pi)

And this driver is perfect, since one can just ELIMINATE the OSVR "layer" and get OpenHMD directly into SteamVR... no daemons, nothing... just plug-and-play! Love it!

---

I've never had such issues on Arch, maybe because I have steam-native-runtime installed, but I'll assume the docker stuff works too.

I decided to do this because I keep having vrcompositor crashing before start, and trying to run steam with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 to check if there's some Arch library causing the crash would not work, since the driver would crash because it can't find the symbol GLIBCXX_3.4.2 in Steam's libstdc++.so (which is GCC 5.1.0).

The docker.sh is just to build the driver using Ubuntu 16.04 with GCC 4.9 on any distro, so it will load just fine with steam libstdc++.so.

Although, now that the driver loads up fine with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0, vrcompositor still crashes! 8''(

---

'm kinda waiting for OpenHMD to finish positional tracking & controller support for the Vive before finishing up this plugin e.g. performance might be bad unless the pose from OpenHMD is updated in a separate thread, but all contributions are very welcome.

So, is this not functional yet? Could it be the cause of vrcompositor crashing then?

Without STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0, vrcompositor was crashing on nvidia libraries, so it looked like a vulkan/nvidia issue at first.

But now with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0, vrcompositor crashes on its own libraries, as you can see here:

do you think it has to do with this driver then?

I was assuming it was something on vrcompositor...

---

Open source steamvr is most likely not going to happen anytime soon, unless someone is making it themselves. https://github.com/ChristophHaag/openvr_api-libre is a start but there is a lot to implement. Most likely OpenXR will be out and most applications will support OpenXR before it gets useful and at this point OpenHMD will be an OpenXR runtime anyway.

Thank god for that... Khronos for the rescue!!! lol

It's being a really frustrating year so far, since steamVR won't run at all on my setup due to vrcompositor crashes. I've started with the standard steamVR OculusDK1 setup ( I got this DK1 for testing ), moved to osvr and now this driver... all to see if I can at least START steamVR... but no luck so far!!

I wish vrcompositor would at least START without any headset/controller, so at least I would be able to debug it on its own to get some support from Valve.

[hradec]

... maybe because I have steam-native-runtime installed...

I just realized... when you mention steam-native-runtime, you're actually referring to a Arch package, right? I just looked on yaourt and found it:

I don't have that installed at all... Didn't even knew about it!

Why do you use it?

Steam work just fine for me without it. It's just steamVR that doesn't, due to crashes on vrcompositor.

According to Valve, STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 forces steam to ignore all the system installed libraries in favor of the ones that come with Steam, like libstdc++.so, libusb, etc.

But i have no idea about steam-native-runtime. Do you think it could help me with the vrcompositor crahes?

[ChristophHaag]

Steam somewhat recently implemented "intelligent" library lookup by default so it only uses libraries from the Steam Runtime if the library isn't found on the system in /usr/lib etc. I think they also have a list of "pinned" libraries where this doesn't happen. It's just a complicated system, but for me it works without any variables like STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0. (RX 480 though, not nvidia)

I decided to do this because I keep having vrcompositor crashing before start, and trying to run steam with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 to check if there's some Arch library causing the crash would not work, since the driver would crash because it can't find the symbol GLIBCXX_3.4.2 in Steam's libstdc++.so (which is GCC 5.1.0).

Well, the old solution was just to delete the worst libraries for this kind of mess:

find ~/.steam/root/ \( -name "libgcc_s.so*" -o -name "libstdc++.so*" -o -name "libxcb.so*" -o -name "libgpg-error.so*" \) -print -delete

And then it would use the ones in /usr/lib etc.

Now with the new library lookup this should not be necessary if you install steam-native-runtime and do not use STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0.

And yes, it's an arch meta package that just has dependencies on all libraries that are part of the steam runtime, so you can install all at once.

So, is this not functional yet? Could it be the cause of vrcompositor crashing then?

No, headset tracking and distortion correction as far as OpenHMD has display parameters work.

It's just that I'm not sure the position updates are smooth enough because it only polls OpenHMD for an updated pose in RunFrame(), where there was a comment in the sample driver.

void RunFrame()
    {
        // In a real driver, this should happen from some pose tracking thread.
        // The RunFrame interval is unspecified and can be very irregular if some other
                // driver blocks it for some periodic task.

It looks okay currently though.

Controllers currently have the "steam controller" model and I only tested briefly with Nolo controllers and their position was weird. Oh yea and the button presses on the controllers still need to be implemented.

That's what I mean.

[ChristophHaag]

Also a short demo video: https://www.youtube.com/watch?v=1J6nERqybu4. Since it's the Vive, it doesn't have positional tracking and to the left there are two steam controller models hovering that aren't tracked yet.