Add instructions for obtaining known-working versions of SteamVR
mncharity opened this issue · comments
OSVR-Docs's Configuring/HTC-Vive currently[1] gives the date and branch number of a known-good SteamVR release, but no hints on how to obtain it. Here is a start at that.
Known-good versions can be obtained using SteamCMD. Installation should be straightforward. Then:
login <YOUR-STEAM-NAME> # and enter password, and Guard.
app_info_request 250820
app_license_request 250820
download_depot 250820 250821 3490945749231862464
quit
Notes: That's download_depot <appid> <depotid> <target manifestid>. The SteamVR appid is 250820. SteamVR's OpenVR Win32 depotid is 250821, and OpenVR Linux depotid is 25083. The currently recommended 2016 July 5 release has a MANIFESTID in the Win32 depot of 3490945749231862464, obtained from here. For linux, that would be download_depot 250820 250823 9183475244149741279.
I am insufficiently familiar with OSVR-Vive to know where those downloaded files should then be copied.
A last thought. My experience of the last few months suggests that "typically the driver is only compatible with the latest stable release of SteamVR" is too optimistic. At least on linux, driver_lighthouse.so on SteamVR stable seems to only rarely be compatible with Valve's public OpenVR openvr_driver.h. For instance, it hasn't been this month.
Thanks for your work.
I now have a little script, who's core is
export HOME=$tmpdir
(cd $tmpdir && ./steamcmd.sh +login $username +app_license_request $appid +download_depot $appid $depotid $manifestid +quit) || exit 1
But I'm finding the downloaded files are truncated, despite steamcmd's claims of success, and the lack of errors in the logs. Even if I Steam>bVerifyAllDownloads "1".
So this approach does not yet seem to be viable.
Thanks for looking into this. I had also tried steamcmd for some time but found it either insufficient or downloading way too much for my tastes. I personally had been using a locally modified version of https://github.com/SteamRE/DepotDownloader to manually download the client runtimes for each platform and a script based on this https://gist.github.com/rpavlik/aeeab316d1f85e2efddd64db58741b2f to grep for the "interface strings" that indicate upstream interface breakage.
You can just change the path in the openvrpaths file (on Linux, think it's in ~/.config/openvr/) to point to where you put the corrected runtime version - OSVR-Vive parses that file, just as SteamVR's vrpathreg tool does. If you'd be willing to update or improve the documentation in any way, that would be greatly appreciated.
(Sorry - I personally no longer have a Vive, so I haven't had as much need or motivation to work on this driver and keep it up to date with Valve's release cycle. The "only compatible with latest stable release" statement replaced an older one from a time when they went a long time without breaking APIs and even steamvr betas interchangeable, to when they presumably went into public release mode in which every beta is incompatible with the latest stable because it introduces new interface versions not found in the "openvr" headers, and each stable typically has a major interface change, so a driver is only compatible with a single stable release of SteamVR. This is also around when they started obscuring/"encrypting" the older releases making it harder to downgrade - impossible using Steam directly, have to use something like steamdb or another tool to look at the history of the stable manifests. Presumably makes support easier for most users, but makes things that are outside of 1 standard deviation more difficult.)
For what it's worth, based on my DepotDownloader snapshots, it looks like the change between 1473196558 and the previous 1467410709, at least on linux, is that IVRSettings_001 became IVRSettings_002 - I haven't checked the public headers to see if they've made that public change available as well, but that's a fairly ancilliary class. I suspect we should actually be able to support both of those at once.
PS. I believe, of course, that since steamdb and DepotDownloader use the same backend library, one could construct a tool based on DepotDownloader or the underlying SteamKit - cross-platform using Mono - to automatically go "back in time" to retrieve a designated stable and OSVR-Vive compatible version of SteamVR, but given that they've "encrypted" the older manifests, I suspect Valve would not look kindly on the community doing that. Perhaps @VRguy has a better idea for collaboration with Valve to support OSVR-Vive since they are an OSVR partner, after all - there was an OSVR-related "beta" (actually old version) of SteamVR for some time for this driver as well as its logical counterpart, SteamVR-OSVR (for using OSVR-supported devices with SteamVR apps), perhaps collaboration to make an OSVR-Vive compatible "beta" channel in SteamVR?
I had also tried steamcmd for some time but found it either insufficient or downloading way too much for my tastes.
Ah, ok. For my own, linux-only app, I just wrote an end-user install script that downloads and runs steamcmd, to obtain an old version of the SteamVR app's "OpenVR Linux" depot. It has the two files I needed, driver_lighthouse.so, and libaitcamlib.co. 15 MB. Thankfully, I didn't need the 1 GB "OpenVR Content" depot. I'd be done, except steamcmd invariably provides only truncated files, while claiming success. I can try debugging that, or script an untruncator, and provide the tails of the files myself, covered by US fair use. But that's a lot of yak hair.
Ok, to recap.
Straightforward end-user installation of OSVR-Vive requires either closely tracking SteamVR OpenVR depot versions, or staying with an old known-to-work version.
It's not currently possible to closely track Steams's OpenVR stable versions, because Valve's OpenVR github itself very much does not.
Obtaining old known-good versions is currently non-trivial, because Valve removed that capability from the Steam UI. It is not known whether this represents a policy obstacle, in addition to being a technical one.
As a technical workaround, DepotDownloader is known to work. On linux too? So end users might be provided with a recipe for it, or a containerized app.
Using SteamCMD might be possible, but may be painful, and is currently buggy.
Valve has been supportive of OSVR-Vive in the past. And might perhaps be again.
Does that sound about right? So, some possibly helpful tasks might include:
- Point users at DepotDownloader.
- Wait for openvr githup to again sync with SteamVR's OSVR depots, and then try updating OSVR-Vive. Perhaps in a separate branch. This is only a temporary fix, as the next SteamVR update, may recreate the problem.
- ... something else?
Hmm. My only experience with Valve, has been in the context of VR and Linux. So my impression is one of a notable lack of transparency and collaboration. But I imagine this might be an atypical sample. Is it plausible that Valve might assist with any of this? That we don't have links to Valve tickets, even if they are WontFix or neglected, makes me wonder if a communication failure is part of all this.
Fyi, steamcmd is now available from linux distribution repositories. And I wrote a node module steamvr-lighthouse-driver-download (which doesn't yet use them).
The current stable release client is the oldest client build any steamvr dependent driver, plugin or app should support.
SteamVR support recommend using steam client beta along with steamvr beta for best Vive performance and SteamVR compatibility.
Seeing eighteen month old steam versions as being listed as the recommended for OSVR-Vive just screams something is way wrong here.
Shouldn't the OSVR-Vive plugin be a component of and packaged with SteamVR-OSVR driver?