error 105 with recent SteamVR #31
Comments
|
Can confirm the latest osvr-vive pre compiled binaries also crash osvr server with error 105. |
|
Looks like some change in steamvr-1496873977, the previous stable steamvr-1495066092 apparently works fine. The only particularly relevant change I see when looking at the grepped interface strings is IVRSystem_015 to IVRSystem_016, but I didn't think this plugin used that interface. Here's the diff between the grepped interface strings of those two versions:
|
|
Just realised both ChristophHaag and I both reported this over a week ago which means something additional to the steamvr home being added to default steam client (latest update) is going on. I shared a steamreport.txt when I asked ValveSoftware/openvr#535 which helps to confirm the 105 crash is related too other things other than the most recent steam client update. |
|
Can anyone confirm that HTC Vive Controller tracking worked before this issue (i.e., with |
|
@georgewsinger Yes, everything was working for me about 5 days ago. |
|
@DuFF14 Can you share or point us to a copy of those older lighthouse drivers that do work? Or did you use steamcmd to download those drivers like mncharity describes at #20 (comment) ? |
|
Are lighthouse drivers cross-platform (that is, would they work on linux)? If so, I second @Balderick in requesting a copy of the lighthouse drivers that work with OSVR-Vive :) |
|
@Balderick @georgewsinger I only have the Windows driver. mncharity's solution should work or something similar. I don't know if we're permitted to distribute old SteamVR builds. |
|
Okay. Thanks for confirming. A lot of good info in mncharity's thread just needs stitched together to make a good how to on how to get osvr-vive working with current steam client versions since we know or can workout last known stable version from dates listed at https://steamdb.info/depot/250823/manifests/ or https://steamdb.info/depot/250821/manifests/ Example For Using SteamCMD
Far from the automated methods being discussed in other thread but hopefully is a workaround for using this build of osvr-vive #30 with current steam client versions |
|
Hi @ChristophHaag, |
|
Hi mars979 Does #30 provide the expected openvrSDK requirements for current steam versions? or we need to wait for openvr 1.0.8? |
|
@Balderick , |
|
Are Valve aware of our need for update? Valve have posted and reposted that new openvr versions should all be backward compatible so that apps, drivers and plugins built with older version do not break because of new version. |
|
Can confirm that it has to be a problem with the latest drivers not some weird configuration. |
|
OpenVR v1.0.8 was just released. It looks like the new |
|
Struggling to apply DuFF14's workaround of reverting drivers which is also described at #24 Can anybody confirm those steamcmd instructions i tried to list above works for them? |
|
@Balderick what numbers did you use in, i.e., Also: after running this command, how did you modify the |
1 Backtracking to steamvr-1495066092Here is my attempt at backtracking to First I ran: $ cd ~
$ mkdir steamcmd
$ cd ~/steamcmd
$ wget http://media.steampowered.com/installer/steamcmd_linux.tar.gz
$ tar -xvzf steamcmd_linux.tar.gz
$ ./steam.sh
Steam> login <username>
Steam> app_info_request 250820 # chosen from https://steamdb.info/app/250820/depots/?branch=v1495066092
Steam> app_license_request 250820 # "
Steam> download_depot 250820 250823 0CB3C3B0C2A8C14D4868C70741AAAF3F # "
Steam> quitI then modified {
"runtime" : [ "/home/george/.local/share/Steam/SteamApps/common/SteamVR" ], // <-- same as before
"config" : [ "/home/george/steamcmd/linux32/steamapps/config" ], // <-- different
"log" : [ "/home/george/.local/share/Steam/logs" ] // <-- same as before
}I think there may be some editing of 2 Unable to Compile #30I am unable to test my efforts above because I cannot get george@ArchBox:~$ git clone --recursive https://github.com/OSVR/OSVR-Vive.git
Cloning into 'OSVR-Vive'...
remote: Counting objects: 1001, done.
remote: Total 1001 (delta 0), reused 0 (delta 0), pack-reused 1001
Receiving objects: 100% (1001/1001), 332.48 KiB | 0 bytes/s, done.
Resolving deltas: 100% (669/669), done.
george@ArchBox:~$ cd OSVR-Viveand then george@ArchBox:~/OSVR-Vive$ git pull origin pull/30/head
remote: Counting objects: 5, done.
remote: Total 5 (delta 4), reused 4 (delta 4), pack-reused 1
Unpacking objects: 100% (5/5), done.
From https://github.com/OSVR/OSVR-Vive
* branch refs/pull/30/head -> FETCH_HEAD
Updating 0b7963f..6eb0638
Fast-forward
PropertyTraits.h | 6 +++---
ServerDriverHost.cpp | 3 +++
ServerDriverHost.h | 1 +
3 files changed, 7 insertions(+), 3 deletions(-)
george@ArchBox:~/OSVR-Vive$ mkdir build
george@ArchBox:~/OSVR-Vive$ cd build
george@ArchBox:~/OSVR-Vive/build$ cmake ..
-- The C compiler identification is GNU 6.3.1
-- The CXX compiler identification is GNU 6.3.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found JsonCpp: /usr/include
-- Boost version: 1.63.0
-- Found the following Boost libraries:
-- system
-- iostreams
-- filesystem
-- regex
-- Found Eigen3: /usr/include/eigen3 (Required is at least version "2.91.0")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/george/OSVR-Vive/buildyields finally the compilation error: george@ArchBox:~/OSVR-Vive/build$ make
Scanning dependencies of target ViveLoaderLib
[ 4%] Building CXX object CMakeFiles/ViveLoaderLib.dir/ChaperoneData.cpp.o
[ 9%] Building CXX object CMakeFiles/ViveLoaderLib.dir/DriverLoader.cpp.o
[ 14%] Building CXX object CMakeFiles/ViveLoaderLib.dir/FindDriver.cpp.o
[ 19%] Building CXX object CMakeFiles/ViveLoaderLib.dir/ServerDriverHost.cpp.o
[ 23%] Building CXX object CMakeFiles/ViveLoaderLib.dir/Properties.cpp.o
[ 28%] Building CXX object CMakeFiles/ViveLoaderLib.dir/Settings.cpp.o
[ 33%] Building CXX object CMakeFiles/ViveLoaderLib.dir/DriverLog.cpp.o
[ 38%] Building CXX object CMakeFiles/ViveLoaderLib.dir/DriverContext.cpp.o
[ 42%] Linking CXX static library libViveLoaderLib.a
[ 42%] Built target ViveLoaderLib
[ 47%] [osvr_convert_json] Generating string literal header from input/HTC_Vive_PRE.json
Scanning dependencies of target ViveDisplayExtractor
[ 52%] Building CXX object CMakeFiles/ViveDisplayExtractor.dir/DisplayExtractor.cpp.o
In file included from /home/george/OSVR-Vive/PropertyHelper.h:51:0,
from /home/george/OSVR-Vive/ServerPropertyHelper.h:52,
from /home/george/OSVR-Vive/DisplayExtractor.cpp:33:
/home/george/OSVR-Vive/PropertyTraits.h:142:38: error: ‘Prop_SecondsFromPhotonsToVblank_Float’ is not a member of ‘vr’
SecondsFromPhotonsToVblank = vr::Prop_SecondsFromPhotonsToVblank_Float,
^~
/home/george/OSVR-Vive/PropertyTraits.h:455:34: error: ‘Prop_SecondsFromPhotonsToVblank_Float’ is not a member of ‘vr’
struct PropertyTypeTrait<vr::Prop_SecondsFromPhotonsToVblank_Float> {
^~
/home/george/OSVR-Vive/PropertyTraits.h:455:34: error: ‘Prop_SecondsFromPhotonsToVblank_Float’ is not a member of ‘vr’
/home/george/OSVR-Vive/PropertyTraits.h:455:75: error: template argument 1 is invalid
ruct PropertyTypeTrait<vr::Prop_SecondsFromPhotonsToVblank_Float> {
^
make[2]: *** [CMakeFiles/ViveDisplayExtractor.dir/build.make:67: CMakeFiles/ViveDisplayExtractor.dir/DisplayExtractor.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/ViveDisplayExtractor.dir/all] Error 2
make: *** [Makefile:128: all] Error 2 |
I used the manifests page to confirm which manifest ids to use after comparing dates of manifest changes and what DuFF14 describes when they confirmed simply rollingbback lighthouse drivers was enough to get osvr-vive working for them and taking the date of when that comment was written and the time span that is described into consideration.
DuFF14's workaround meant no editing of that file is needed as you just drop the newly downloaded drivers straight into your current steamvr install. I could not reproduce DuFF14s workaround I have been trying to test osvr-vive using the latest build69 pre compiled binaries |
|
Hi all, I added a PR - #32 to update OSVR-Vive to the latest OpenVR SDK v1.0.8 and with the current changes that are in places, the plugin compiles and tracking works (HMD and controllers). The latest interfaces that were added in the recent version of OpenVR will require some additional work and tweaks, but at the moment you can still use the plugin. I'm also including below pre-compiled binaries (with VS 2013) of the updated OSVR-Vive plugin (32 and 64 bit) that works with latest lighthouse driver: Please let us know if you run into any errors, issues with the current build (more updates are to come soon). And feel free to contribute to the existing PR. |
|
Works for me. Thanks! |
|
@mars979 When I run ViveDisplayExtractor.exe with your DLL from Google Drive I still get SteamVR says HDM and Lighthouses are up to date. OSVR is build 356. |
|
Can confirm starting osvr server with the upstream pre compiled com_osvr_Vive.dll binaries/plugin in place no longer causes osvr server to crash with error 105 however osvr-vive plugin does not load when starting osvr server configured for an osvr hdk 1.4 with a warning Trying to run vivedisplayextractor gives which is described in #24 Setup |
|
@MrMinimal: I am facing a similar issue, although I did not use the the DLL from Google Drive (I'm running Linux and compiled them from #32). |
|
Hi everyone, @MrMinimal, @Balderick |
|
Hi mars979, I do not have a vive hmd and am trying to work out how to use osvr hdk with its own native tracker along with two Vive controllers using lighthouse tracking in steamvr. I used https://github.com/OSVR/OSVR-Docs/blob/master/Configuring/HTC-Vive.md to install osvr-vive and am using your precompiled vive.dll from your 108branch. Using the info from https://github.com/OSVR/OSVR-Docs/blob/master/Extending-OSVR/ConfiguringHDKViveTracking.md is really for osvr devs to test vive support in osvr apps but thought i could easily adjust semantic paths and aliases to suit my multi vebnndor setup so that tracker viewer can be used to show osvr hmd working with two vive controllers. I have asked openvr devs the openvr way to achieve what i need at ValveSoftware/openvr#535 and asked osvr users the osvr way at https://www.reddit.com/r/OSVR/comments/6fyw8h/how_to_add_vive_controllers_to_osvr_hdk_setup/ I also started https://www.reddit.com/r/OSVR/comments/6ht8kp/osvrvive_is_now_fixed_but/ to discuss what i am trying to do to save derailing this issue here. Because my osvr hdk ever only gets used to enjoy openvr apps being run through steamvr runtime I have long seen the importance of steamvr room layout GUI showing osvr devices as exactly how they are positioned in real life before expecting them to work well so see this as more of an openvr thing than an osvr thing. That is why only the last section of https://github.com/OSVR/OSVR-Docs/blob/master/Extending-OSVR/ConfiguringHDKViveTracking.md seems to have helped with |
|
@mars979 |
|
Hi everyone, I merged PR #32 that fixes Thanks for supporting OSVR! |
|
Just tried it, PR #32 fixed DisplayExtractor error 105 on Windows right away. Thank you so much for the quick support! |
|
Updating to the 70build precompiled osvr-vive binaries along with latest runtime binaries and making sure the osvr_server_config_vive.sample.json looks like what i usualy use for osvr hdk lets osvr-vive plugin load
and even get tracker viewer showing three tracked devices. Noticed powering on vive controllers with osvr server does not start steamvr, which is handy. Only one controller showed up in tracker viewer but saw simply restarting osvr server with both controllers powered on (without steamvr running) allowed tracker viewer to pick up the three tracked devices. Can confirm displayectractor.exe does not crash at all too. Even when i run it simply does not detect any tracked devices and asks for |
|
@Balderick Can you provide more information on your working build? What I see is build 70 of osvr-vive, but what steamVR-Version are you using, and what does your osvr_server_config_vive.sample.json look like? We are trying here to get osvr-vive running since days with no success (ViveDisplayExtractor not being able to read serial no) :( |
|
Instead of using ViveDisplayExtractor you can also use the mesh from the OSVR-Vive-Libre repository: https://raw.githubusercontent.com/collabora/OSVR-Vive-Libre/master/config/HTC_Vive_meshdata.json and put it wherever the osvr_server_config.vive.sample.json config is expecting it. |
|
Thank you @ChristophHaag, but that didn't help unfortunately :( My image inside the vive is still left eye only and distorted/tilted. We have no idea what to do further which is such a pity. |
|
@ChristophHaag Interesting that a single config works "well enough" for some users - I assumed the fact that each Vive having its own config (and per-eye projection and distortion, even!) meant that there was sufficient manufacturing variation that the per-device extraction step was required. A "sample file" generated by someone and submitted to this repo as an apache 2.0 contribution (rather than gpl) would probably be accepted. |
|
@ChristophHaag @Balderick |
|
Now using a full vive vr setup so have not been trying to use osvr-vive like described above. I'll try reinstalling osvr to help with some feedback when using vive to access osvr apps running in osvr runtime. Did openvr api update to .11 break osvr-vive? EDIT: Nope. It didn't. |
|
Can confirm osvr-vive loads lighthouse drivers without errors in osvr server with latest pre compiled osvr runtime, pre compiled osvr-vive and with the latest steamvr-osvr drivers in place. Gives bad pose in tracker viewer - still need to run an osvr app to test. osvr-vive is loading lighthouse drivers from current steamvr beta installed in latest steam client beta and the .vive.sample.json was saved as osvr_server_config.json before launching osvr server. OSVR server console spews Tested with just vive hmd and one base station. Trying to launch osvr_palace_v0.6.16.4 app nothing gets rendered in vive hmd though steamvr tracking is moving view and position as expected in the desktop windowed instance but with bad pose and position. Trying to launch Parabolic-Alpha-Osvr i get So vive display extractor tool was run which gave but after restarting osvr server still get balckscreen in hmd when trying to run osvr apps and seems to be described at #34 |
|
I have this issue with the latest version of OSVR-Vive plugin. June 01 13:01:11.526 info [OSVR]: Logging for C:\Program Files\OSVR\Runtime\bin\osvr_server.exe |
|
I am in the same boat as @cronybox. My environment:
I get the impression that Valve is not particularly committed to maintaining backwards compatibility in the driver-facing part(s) of the OpenVR API? |
|
I believe Valve keeps the old interfaces in SteamVR, so if you update SteamVR you can usually still load older SteamVR plugins. What they are doing here is not just adding new versions of the interfaces to SteamVR, but they are updating the lighthouse plugin to the new interfaces, and in the lighthouse plugin they do not keep any backwards compatible stuff. To load a recent lighthouse plugin you also need recent SteamVR, or in this case, an updated plugin loader from OSVR. It does not look like OSVR currently has a lot of resources to spare to work on stuff like this and the changes do not look trivial (I think it has to do with Valve's new input system that supposedly is approaching something similar to OpenXR). You can also watch OpenHMD and libsurvive, who are working on open source implementations of lighthouse tracking. They might be getting to a usable state in the not too far future. |
|
Thanks @ChristophHaag for the clarification -- your explanation makes perfect sense. I suppose we have to consider the Lighthouse plugin to be "private property" of Vavle's own Vive driver, and that Valve is under no obligation to maintain compatibility with older interfaces. These sorts of breakages for the OSVR-Vive plugin are, unfortunately, inevitable. For others who encounter this same issue, there is a SteamVR Beta from earlier this year ( |
|
Karl, I don't have a Vive anymore so there's not much likelihood of a change coming from me. It is true that Valve owes no stability here: @JoeLudwig has told me several times to my face that the way this works is not a supported use case vand I shouldn't do this, but given that a: it's already done and b: it's the only way I could find to extract the distortion mesh, it's just been updated over time as people have had time/resources and need. They have been pretty good keeping the openvr SDK repo up to date with the latest stable binaries of steam VR after the first little period, which I think is all we can really hope for at this point. It's not that they are breaking backwards compatibility: it's that their first-party driver is always built against/using the latest version of their driver-facing interfaces reasonably and logically enough), so this plugin breaks after each interface bump until it implements those new interfaces as well. (Their driver host implements multiple versions of these interfaces, providing compatibility over time with a range of drivers, but that doesn't solve the problem more or less uniquely faced by this particular plugin and its cousins such as the VRUI Vive support) This can be observed by grepping the strings of the lighthouse driver over time for the particular naming pattern of the interface/version id used in openvr - pretty sure I've made a gist with my script for this, possibly even linking it in an issue or elsewhere. I presently neither have time, resources, nor need hence I'm encouraging others, particularly those who would use or benefit from this, to look into it. I'm happy to offer specific advice if any roadblocks are hit, as I have done for the other contributors to this repo. I do know that the recent changes in openvr are somewhat major, so I imagine it will mostly be the same process that I initially used to write this driver after a few startup steps: update the openvr SDK, build and run the traits generation tool (editing/enhancing it if required) and paste the results into the corresponding header, then using a simple "stub" driver host app (still included with the OSVR-Vive source, but might not be built by default) implement or modify interfaces one by one until the driver loads and reports useful data. There is very little that is actually OSVR specific in this codebase, it's mostly just a clean reimplementation (based on header file, and only implementing one version of interfaces at a time) of the driver host portion of steamvr. It's a fairly mechanical process, really, as long as the openvr header matches the current binary drivers (and as long as any underlying models/data structures can be imagined and implemented). So, it should be roughly the same difficulty no matter a contributor's background if they have hardware to test it on. (You don't need hardware for the initial fixes, since it should load the lighthouse driver even without hardware, but to actually make sure it functions you need hardware.) I didn't have much in the way of openvr experience or expertise when I started this, though working on a project like this repo is a good way to quickly develop some, since you have to understand on some level how the parts of their system work together in order to implement it. Hope this helps! |
|
I can confirm that I told @rpavlik right to his face. :) The source of problems here is pretty much what Ryan said: All the backward compatibility is built into vrserver in SteamVR. So in the time between when SteamVR updates its beta and when a new SDK is released anything that tries to load or hook closed source drivers is going to be incompatible. |
|
@karlsvec , |
|
@JoeLudwig So perhaps I can ask a related question: I think since the Vive Tracker release there's a way to use SteamVR without having it "own the display surface", which would mean that I think it would be capable of doing everything this plugin does, except for extracting a distortion mesh. Is there any potential for adding an API so we could extract the distortion mesh the way we did with this vrserver-reimplementation project but a less fragile approach? I do appreciate the immense trade-offs inherent in that question. (and if you make a lighthouse openxr driver that is runtime-independent it's a relatively moot point...) |
|
I think anything that tries to pretend to be vrserver is doomed to fail. That might be because I spend my days adding new stuff to vrserver, much of which requires interface changes. If you want to let the Lighthouse driver give you poses but handle the present to the display yourself, you could do that by writing a virtual display driver. They're intended for wireless displays, but they do get the texture instead of driver_lighthouse. That would involve using the rest of the SteamVR runtime and just handling the display bit at the end. |
I'm compiling with my pull request #30.
This config worked before, so presumably a SteamVR/lighthouse update broke it.
"Got error code 105" is probably the error that makes it fail.
The text was updated successfully, but these errors were encountered: