OSVR/OSVR-Vive

error 105 with recent SteamVR

ChristophHaag opened this issue · 46 comments

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.

HmdError_Init_InterfaceNotFound (105) - The specific interface function requested by VR_Init or VR_GetGenericInterface could not be found. Is the SDK being used newer than the installed runtime?

June 03 12:40:20.902 info [OSVR]: Logging for /usr/bin/osvr_server
June 03 12:40:20.902 info [OSVR Server]: Using config file osvr_server_config.vive.sample.json from command line argument.
June 03 12:40:20.902 info [OSVR Server]: Attempting to load config file 'osvr_server_config.vive.sample.json'.
June 03 12:40:20.902 info [OSVR Server]: Constructing server as configured...
June 03 12:40:20.904 info [OSVR Server]: Loading auto-loadable plugins...
June 03 12:40:20.969 info [OSVR Server]: Loading plugins...
June 03 12:40:20.969 info [OSVR Server]: Instantiating configured drivers...
June 03 12:40:20.971 info [OSVR Server]: Display descriptor found and parsed from config file.
June 03 12:40:20.971 info [OSVR Server]: RenderManager config found and parsed from the config file.
June 03 12:40:20.971 info [OSVR Server]: Triggering automatic hardware detection...
June 03 12:40:20.971 info [OSVR Server]: Registering shutdown handler...
June 03 12:40:20.971 info [OSVR Server]: Starting server mainloop: OSVR Server is ready to go!
June 03 12:40:20.971 info [OSVR Server]: Performing hardware auto-detection.
June 03 12:40:21.261 info [OSVR-Vive]: Found the Vive driver at /home/chris/.local/share/Steam/SteamApps/common/SteamVR/drivers/lighthouse/bin/linux64/driver_lighthouse.so
June 03 12:40:21.261 info [OSVR-Vive]: Driver config dir is: /home/chris/.local/share/Steam/config/lighthouse
June 03 12:40:21.261 info [OSVR Server]: Added device: com_osvr_Vive/ViveSync
June 03 12:40:21.270 info [OSVR Server]: Sent path tree to clients.
Got error code 105
June 03 12:40:21.271 error [OSVR-Vive]: Could not start the server device provider in the Vive driver. Exiting.
June 03 12:40:21.271 error [OSVR-Vive]: Vive driver startup failed.
June 03 12:40:21.271 info [OSVR-Vive]:  Unloading to perhaps try again later.

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:

screenshot 871

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 steamvr-1495066092 @rpavlik)?

@georgewsinger Yes, everything was working for me about 5 days ago.
Current workaround for me is to revert the lighthouse driver at C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\lighthouse\bin\win64

@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

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

For linux, that would be

download_depot 250820 250823 9183475244149741279

Notes: That's download_depot [appid][depotid][target manifestid] where 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 https://steamdb.info/depot/250821/manifests/

Once you have the downloaded files 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.

Sometimes just replacing lighthouse drivers in your current steam install can be enough to workaround osvr-vive crashing osvr server with error 105

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,
It appears that there has been an update to the lighthouse driver with one of the latest SteamVR update and which made it incompatible with Vive plugin, because there is a new interface added but the OpenVR SDK was not yet updated to reflect the changes.
We should be able to get it fixed, once there is a new version of OpenVR SDK released.

Hi mars979

Does #30 provide the expected openvrSDK requirements for current steam versions?

or we need to wait for openvr 1.0.8?

@Balderick ,
Unfortunately it wouldn't work. Christoph mentioned in the issue that he also tried a build with #30, but it didn't work for him neither. The new interface hasn't been added to the OpenVR SDK, so we'll need to wait for a new release.

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.
Did a fresh install of my system. Code 105 still showing on Windows.

OpenVR v1.0.8 was just released.

It looks like the new IVRDriverManager component should be fairly easy to implement.

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., download_depot 250820 250821 3490945749231862464? I'm about to try this technique myself but haven't tracked down the right appid's and so forth for the last known stable version of SteamVR to work with OSVR-Vive.

Also: after running this command, how did you modify the openvrpaths.vrpath?

1 Backtracking to steamvr-1495066092

Here is my attempt at backtracking to steamvr-1495066092:

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> quit

I then modified /root/.openvr/openvrpaths.vrpath to

{
	"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 openvrpathths.vrpath that I'm missing though, as I only edited a single line. For example, it's not clear how OSVR will be able to find the location of ~/steamcmd/linux32/steamapps/common/SteamVR/drivers/lighthouse/bin/linux32/driver_lighthouse.so
from this JSON config since none of the contents of /root/.openvr/openvrpaths.vrpath matches the drivers folder.

2 Unable to Compile #30

I am unable to test my efforts above because I cannot get OSVR-Vive to compile at #30:

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-Vive

and 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/build

yields 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

georgewsinger commented 9 hours ago • edited
@Balderick what numbers did you use in, i.e., download_depot 250820 250821 3490945749231862464? I'm about to try this technique myself but haven't tracked down the right appid's and so forth for the last known stable version of SteamVR to work with OSVR-Vive.

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.

Also: after running this command, how did you modify the openvrpaths.vrpath?

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:
https://drive.google.com/file/d/0B55SPVLw_B18c2NfSzRKc2podFk/view

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

Got error code 105
[DisplayExtractor] Error: could not start the server device provider in the Vive driver. Exiting.

SteamVR says HDM and Lighthouses are up to date. OSVR is build 356.
Am I doing something wrong?

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

June 17 13:46:44.471 info [OSVR Server]: Loading auto-loadable plugins...
June 17 13:46:44.478 warning [PluginHost]: Failed to load plugin com_osvr_Vive: Failed to load the module C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive

Trying to run vivedisplayextractor gives

C:\Program Files\OSVR\Runtime\bin>ViveDisplayExtractor.exe
June 17 15:37:53.044 info [OSVR]: Logging for C:\Program Files\OSVR\Runtime    \bin\ViveDisplayExtractor.exe
Got error code 105
[DisplayExtractor] Error: could not start the server device provider in the Vive driver. Exiting.

which is described in #24

Setup
Latest pre compiled osvr runtime
Latest pre-compiled steamvr-osvr drives
Current steam client beta
Current steamvr beta
64 arch com_osvr_Vive from https://drive.google.com/file/d/0B55SPVLw_B18c2NfSzRKc2podFk/view

@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,
Thanks so much for the feedback on the updated plugin! It looks like there was an issue with DisplayExtractor, so I fixed it in the latest commit.

@MrMinimal,
If the DisplayExtractor is still not working for you, then please let me know.

@Balderick
When OSVR server says that plugin could not be loaded, it could be for multiple reasons such as mismatched binaries (32 vsv 64 bit), missing dlls, or some other reason.
Please try to download the latest OSVR Runtime from here (released today), which supports runtime verbosity flags and then run OSVR Server from cmd line - osvr_server.exe osvr_server_config.json -v and let me know what errors do you get.

Hi mars979,
After updating runtime and doublechecking 64 bit vive dll is being used with 64 bit runtime starting osvr server like you asked gives

June 20 05:54:55.424 info [OSVR]: Logging for C:\Program Files\OSVR\Runtime\bin\osvr_server.exe
June 20 05:54:55.425 debug [OSVR Server]: Verbose logging enabled.
June 20 05:54:55.425 info [OSVR Server]: Using config file osvr_server_config.json from command line argument.
June 20 05:54:55.425 info [OSVR Server]: Attempting to load config file 'osvr_server_config.json'.
June 20 05:54:55.425 info [OSVR Server]: Constructing server as configured...
June 20 05:54:55.428 info [OSVR Server]: Loading auto-loadable plugins...
June 20 05:54:55.428 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Multiserver.dll'...
June 20 05:54:55.428 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Multiserver.dll
June 20 05:54:55.430 debug [PluginHost]: Successfully loaded plugin: com_osvr_Multiserver
June 20 05:54:55.430 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_VideoBasedHMDTracker.dll'...
June 20 05:54:55.430 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_VideoBasedHMDTracker.dll
June 20 05:54:55.432 debug [PluginHost]: Successfully loaded plugin: com_osvr_VideoBasedHMDTracker
June 20 05:54:55.432 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_VideoCapture_OpenCV.manualload.dll'...
June 20 05:54:55.432 debug [PluginHost]: Ignoring manual-load plugin: com_osvr_VideoCapture_OpenCV.manualload
June 20 05:54:55.432 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive.dll'...
June 20 05:54:55.432 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive.dll
June 20 05:54:55.433 debug [PluginHost]: Failed: Failed to load the module C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive.dll
June 20 05:54:55.433 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive
June 20 05:54:55.434 debug [PluginHost]: Failed: Failed to load the module C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive
June 20 05:54:55.434 warning [PluginHost]: Failed to load plugin com_osvr_Vive: Failed to load the module C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive
June 20 05:54:55.434 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_deadreckoningrotation.dll'...
June 20 05:54:55.435 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_deadreckoningrotation.dll
June 20 05:54:55.435 debug [PluginHost]: Successfully loaded plugin: org_osvr_filter_deadreckoningrotation
June 20 05:54:55.435 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_oneeuro.dll'...
June 20 05:54:55.436 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_oneeuro.dll
June 20 05:54:55.436 debug [PluginHost]: Successfully loaded plugin: org_osvr_filter_oneeuro
June 20 05:54:55.437 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_videoimufusion.dll'...
June 20 05:54:55.437 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_videoimufusion.dll
June 20 05:54:55.437 debug [PluginHost]: Successfully loaded plugin: org_osvr_filter_videoimufusion
June 20 05:54:55.438 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_unifiedvideoinertial.dll'...
June 20 05:54:55.440 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_unifiedvideoinertial.dll
June 20 05:54:55.441 debug [PluginHost]: Successfully loaded plugin: org_osvr_unifiedvideoinertial

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 what I am trying to do getting osvr hmd working with vive controllers in steamvr. Simply enabling multiple drivers and disabling requirHmd in steamvr.vrsettings config file is all that is needed to allow steamvr to see and use osvr hmd along with osvr hdk but steamvr creates a very bad pose as it places controllers away from osvr hmd in a Irrelative manner. I see this is as more of openvr issue with possibly steamvr-osvr driver updates possibly being able to help out so have just been updating the openvr issue that i opened and referred to above.

@mars979
Really appreciate the effort, I will as soon as I have got my development environment set up. Had used the pre compiled binaries of yours before

Hi everyone,

I merged PR #32 that fixes Got error code 105 and DisplayExtractor crash issues into the master and the latest binaries are available for download on http://access.osvr.com/binary/vive
If you find new issues with the latest version of the plugin, please file them, and we will get them fixed!

Thanks for supporting OSVR!
-Georgiy

Just tried it, PR #32 fixed DisplayExtractor error 105 on Windows right away.
Works like a charm now.

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 allows lighthouse tracked devices be used with osvr hdk using its own native tracker.

screenshot 12

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.
screenshot 13

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 Enter to be pressed to quit gracefully.

@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.
It works well enough for my Vive.

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
Do you still have this issue with the latest version of OSVR-Vive plugin?

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.
badpose

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

Dec 11 19:41:29.332 info [OSVR]: Logging for C:\Program Files\OSVR\Runtime\bin\osvr_server.exe
Dec 11 19:41:29.332 info [OSVR Server]: Using default config file - pass a filename on the command line to use a different one.
Dec 11 19:41:29.332 info [OSVR Server]: Attempting to load config file 'osvr_server_config.json'.
Dec 11 19:41:29.332 info [OSVR Server]: Constructing server as configured...
Dec 11 19:41:29.332 info [OSVR Server]: Loading auto-loadable plugins...
Dec 11 19:41:29.332 info [OSVR Server]: Loading plugins...
Dec 11 19:41:29.332 info [OSVR Server]: Instantiating configured drivers...
Dec 11 19:41:29.332 info [OSVR Server]: Display descriptor found and parsed from config file.
Dec 11 19:41:29.347 info [OSVR Server]: RenderManager config found and parsed from the config file.
Dec 11 19:41:29.347 info [OSVR Server]: Triggering automatic hardware detection...
Dec 11 19:41:29.347 info [OSVR Server]: Registering shutdown handler...
Dec 11 19:41:29.347 info [OSVR Server]: Starting server mainloop: OSVR Server is ready to go!
Dec 11 19:41:29.347 info [OSVR Server]: Performing hardware auto-detection.
Dec 11 19:41:29.447 info [OSVR-Vive]: Found the Vive driver at C:/Program Files (x86)/Steam/steamapps/common/SteamVR/drivers/lighthouse/bin/win64/driver_lighthouse.dll
Dec 11 19:41:29.447 info [OSVR-Vive]: Driver config dir is: C:/Program Files (x86)/Steam/config/lighthouse
Dec 11 19:41:29.447 info [OSVR Server]: Added device: com_osvr_Vive/ViveSync
Dec 11 19:41:29.447 info [OSVR Server]: Sent path tree to clients.
Dec 11 19:41:29.724 info [ServerDriverHost]: TrackedDeviceAdded(LHR-F93FBB2D)
Dec 11 19:41:29.724 info [OSVR-Vive]: Assigned sensor ID 0 to
Dec 11 19:41:29.724 info [OSVR Server]: Added device: com_osvr_Vive/Vive
Dec 11 19:41:29.725 info [OSVR-Vive]: Vive driver finished startup successfully!
Dec 11 19:41:29.725 info [OSVR Server]: Sent path tree to clients.
OSVR-ViveSensor 0 changed status from 'Uninitialized' to 'Calibrating (Out of Range)'
Dec 11 19:41:33.207 info [ServerDriverHost]: TrackedDeviceAdded(LHB-8583D660)
Dec 11 19:41:33.207 info [OSVR-Vive]: Assigned sensor ID 3 to
OSVR-ViveSensor 3 changed status from 'Uninitialized' to 'Running (Out of Range)'
OSVR-ViveSensor 0 changed status from 'Calibrating (Out of Range)' to 'Calibrating (In Progress)'
OSVR-ViveSensor 0 changed status from 'Calibrating (In Progress)' to 'Running (OK)'
OSVR-ViveSensor 3 changed status from 'Running (Out of Range)' to 'Running (OK)'
OSVR-ViveSensor 0 changed status from 'Running (OK)' to 'Running (Out of Range)'
OSVR-ViveSensor 0 changed status from 'Running (Out of Range)' to 'Running (OK)'
OSVR-ViveSensor 0 changed status from 'Running (OK)' to 'Running (Out of Range)'
OSVR-ViveSensor 0 changed status from 'Running (Out of Range)' to 'Running (OK)'
vrpn: Connection request received from 127.0.1.0: 127.0.1.0 86385
Dec 11 19:50:30.046 info [OSVR Server]: Performing hardware auto-detection.
Dec 11 19:50:30.079 info [OSVR Server]: Sent path tree to clients.
vrpn: Connection request received from 127.0.1.0: 127.0.1.0 86387

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.
badpose3

Trying to launch Parabolic-Alpha-Osvr i get
badpose2 on desktop window and nothing rendered in hmd.

So vive display extractor tool was run which gave

C:\Users\Tron>"C:\Program Files\OSVR\Runtime\bin\ViveDisplayExtractor.exe"
Dec 11 21:25:22.028 info [OSVR]: Logging for C:\Program Files\OSVR\Runtime\bin\ViveDisplayExtractor.exe
Dec 11 21:25:22.353 info [ServerDriverHost]: TrackedDeviceAdded(LHR-F93FBB2D)

[DisplayExtractor] Device with s/n LHR-F93FBB2D activated, assigned ID 0
[DisplayExtractor] Got 1 tracked devices at startup
[DisplayExtractor] -- it's a display, too! We'll extract its display parameters now.
Error trying to read the manufacturer of the attached HMD...
Error trying to read the model of the attached HMD...
[getStringProperty] Got an initial return value larger than the buffer size: ret = 1070586544, buf.size() = 32
[getStringProperty] THIS SHOULDN'T HAPPEN: Got a return value larger than the buffer size: ret = 1070586544, buf.size() = 32
Error trying to read the serial number of the attached HMD...

[DisplayExtractor]


[DisplayExtractor] Successfully extracted display parameters from Vive.

[DisplayExtractor] Writing distortion mesh data file:
C:/Program Files/OSVR/Runtime/bin/displays/HTC_Vive_meshdata.json

[DisplayExtractor] Writing display descriptor file:
C:/Program Files/OSVR/Runtime/bin/displays/HTC_Vive.json

[DisplayExtractor] Be sure to re-run this tool if you move your OSVR Server installation, as the generated files include absolute paths.
[DisplayExtractor] Press enter to quit...

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.
Code 105 showing on Windows again.

June 01 13:01:11.526 info [OSVR]: Logging for C:\Program Files\OSVR\Runtime\bin\osvr_server.exe
June 01 13:01:11.526 debug [OSVR Server]: Verbose logging enabled.
June 01 13:01:11.526 info [OSVR Server]: Using config file osvr_server_config.json from command line argument.
June 01 13:01:11.527 info [OSVR Server]: Attempting to load config file 'osvr_server_config.json'.
June 01 13:01:11.527 info [OSVR Server]: Constructing server as configured...
June 01 13:01:11.533 info [OSVR Server]: Loading auto-loadable plugins...
June 01 13:01:11.534 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Multiserver.dll'...
June 01 13:01:11.534 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Multiserver.dll
June 01 13:01:11.536 debug [PluginHost]: Successfully loaded plugin: com_osvr_Multiserver
June 01 13:01:11.536 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_VideoBasedHMDTracker.dll'...
June 01 13:01:11.536 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_VideoBasedHMDTracker.dll
June 01 13:01:11.540 debug [PluginHost]: Successfully loaded plugin: com_osvr_VideoBasedHMDTracker
June 01 13:01:11.540 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_VideoCapture_OpenCV.manualload.dll'...
June 01 13:01:11.541 debug [PluginHost]: Ignoring manual-load plugin: com_osvr_VideoCapture_OpenCV.manualload
June 01 13:01:11.541 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive.dll'...
June 01 13:01:11.541 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/com_osvr_Vive.dll
June 01 13:01:11.541 debug [PluginHost]: Successfully loaded plugin: com_osvr_Vive
June 01 13:01:11.541 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_deadreckoningrotation.dll'...
June 01 13:01:11.541 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_deadreckoningrotation.dll
June 01 13:01:11.542 debug [PluginHost]: Successfully loaded plugin: org_osvr_filter_deadreckoningrotation
June 01 13:01:11.542 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_oneeuro.dll'...
June 01 13:01:11.542 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_oneeuro.dll
June 01 13:01:11.544 debug [PluginHost]: Successfully loaded plugin: org_osvr_filter_oneeuro
June 01 13:01:11.544 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_videoimufusion.dll'...
June 01 13:01:11.544 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_filter_videoimufusion.dll
June 01 13:01:11.545 debug [PluginHost]: Successfully loaded plugin: org_osvr_filter_videoimufusion
June 01 13:01:11.545 debug [PluginHost]: Examining plugin 'C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_unifiedvideoinertial.dll'...
June 01 13:01:11.545 debug [PluginHost]: Trying to load a plugin with the name C:/Program Files/OSVR/Runtime/bin/osvr-plugins-0/org_osvr_unifiedvideoinertial.dll
June 01 13:01:11.546 debug [PluginHost]: Successfully loaded plugin: org_osvr_unifiedvideoinertial
June 01 13:01:11.546 info [OSVR Server]: Loading plugins...
June 01 13:01:11.546 info [OSVR Server]: Instantiating configured drivers...
June 01 13:01:11.547 info [OSVR Server]: Aliases found and parsed from config file.
June 01 13:01:11.548 info [OSVR Server]: Display descriptor found and parsed from config file.
June 01 13:01:11.548 info [OSVR Server]: RenderManager config found and parsed from the config file.
June 01 13:01:11.548 info [OSVR Server]: Triggering automatic hardware detection...
June 01 13:01:11.549 info [OSVR Server]: Registering shutdown handler...
June 01 13:01:11.549 info [OSVR Server]: Starting server mainloop: OSVR Server is ready to go!
June 01 13:01:11.549 info [OSVR Server]: Performing hardware auto-detection.
June 01 13:01:11.655 info [OSVR Server]: Added device: com_osvr_Multiserver/OSVRHackerDevKit0
June 01 13:01:11.656 info [OSVR Server]: Added device: com_osvr_Multiserver/OSVRHackerDevKitPrediction0
June 01 13:01:11.712 info [OSVR-Vive]: Found the Vive driver at C:/Program Files (x86)/Steam/steamapps/common/SteamVR/drivers/lighthouse/bin/win64/driver_lighthouse.dll
June 01 13:01:11.712 info [OSVR-Vive]: Driver config dir is: C:/Program Files (x86)/Steam/config/lighthouse
June 01 13:01:11.712 info [OSVR Server]: Added device: com_osvr_Vive/ViveSync
June 01 13:01:11.713 debug [OSVR Server]: Path tree updated or connection detected
June 01 13:01:11.713 info [OSVR Server]: Sent path tree to clients.
June 01 13:01:11.714 debug [Properties]: addDeviceAt 0
June 01 13:01:11.714 debug [DriverLog]: Got an unhandled interface type version - IVRServerDriverHost_005
Got error code 105
June 01 13:01:11.714 debug [DriverLoader]: osvr::vive::DriverLoader::reset() - unloading driver
June 01 13:01:11.715 error [OSVR-Vive]: Could not start the server device provider in the Vive driver. Exiting.
June 01 13:01:11.715 error [OSVR-Vive]: Vive driver startup failed.
June 01 13:01:11.715 info [OSVR-Vive]: Unloading to perhaps try again later.

I am in the same boat as @cronybox.

My environment:

  • Windows 10 x64
  • latest (non-Beta) SteamVR
  • latest pre-built OSVR Runtime (0.6.2118-gd690c5ef, build 12)
  • latest pre-built OSVR-Vive plugin (build 73)

osvr-server dies with complaints about an incompatible version for IVRServerDriverHost:

June 04 12:54:42.989 info [OSVR Server]: Sent path tree to clients.
June 04 12:54:42.996 debug [Properties]: addDeviceAt 0
June 04 12:54:42.997 debug [DriverLog]: Got an unhandled interface type version - IVRServerDriverHost_005
Got error code 105
June 04 12:54:42.999 debug [DriverLoader]: osvr::vive::DriverLoader::reset() - unloading driver
June 04 12:54:43.001 error [OSVR-Vive]: Could not start the server device provider in the Vive driver. Exiting.
June 04 12:54:43.001 error [OSVR-Vive]: Vive driver startup failed.
June 04 12:54:43.001 info [OSVR-Vive]:  Unloading to perhaps try again later.

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 (openvr-inputemulator-temporary) that appears to work with current builds of the OSVR-Vive plugin. Hopefully this beta will be available long enough until somebody from the OSVR community with OpenVR expertise can find time to contribute the required update(s) to the plugin.

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 ,
Please see the WIP branch https://github.com/OSVR/OSVR-Vive/tree/openvr1015 that updates the Vive to the latest OpenVR 1.0.15 version. Like @rpavlik said, there are indeed a lot of changes since the last time the plugin was updated and it needs plenty of modifications and new implementations (specifically with new Input system API). Hopefully we'll get something working very soon

@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.