Unable to Use #32 on Linux

Question

Unable to Use #32 on Linux

georgewsinger opened this issue 7 years ago · comments

I'm running Arch Linux:

$ cd ~
$ git clone --recursive https://github.com/OSVR/OSVR-Vive.git
$ cd OSVR-Vive
$ git pull origin pull/32/head
$ mkdir build
$ cd build
$ cmake ..
$ make

This yields the following build error:

Scanning dependencies of target ViveLoaderLib
[  4%] Building CXX object CMakeFiles/ViveLoaderLib.dir/ChaperoneData.cpp.o
[  8%] Building CXX object CMakeFiles/ViveLoaderLib.dir/DriverContext.cpp.o
In file included from /home/george/OSVR-Vive/DriverContext.h:30:0,
                 from /home/george/OSVR-Vive/DriverContext.cpp:26:
/home/george/OSVR-Vive/DriverManager.h:39:51: error: expected class-name before ‘{’ token
 class DriverManager : public vr::IVRDriverManager {
                                                   ^
/home/george/OSVR-Vive/DriverManager.h:43:40: error: ‘vr::DriverId_t’ has not been declared
     virtual uint32_t GetDriverName(vr::DriverId_t nDriver, char *pchValue,
                                        ^~~~~~~~~~
In file included from /home/george/OSVR-Vive/DriverContext.h:32:0,
                 from /home/george/OSVR-Vive/DriverContext.cpp:26:
/home/george/OSVR-Vive/Resources.h:38:43: error: expected class-name before ‘{’ token
 class Resources : public vr::IVRResources {
                                           ^
In file included from /home/george/OSVR-Vive/DriverContext.cpp:26:0:
/home/george/OSVR-Vive/DriverContext.h:67:9: error: ‘IVRDriverManager’ in namespace ‘vr’ does not name a type
     vr::IVRDriverManager *m_pVRDriverManager;
         ^~~~~~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.h:68:9: error: ‘IVRResources’ in namespace ‘vr’ does not name a type
     vr::IVRResources *m_pVRResources;
         ^~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.cpp: In constructor ‘vr::DriverContext::DriverContext()’:
/home/george/OSVR-Vive/DriverContext.cpp:39:7: error: class ‘vr::DriverContext’ does not have any field named ‘m_pVRDriverManager’
       m_pVRDriverManager(nullptr), m_pVRResources(nullptr) {}
       ^~~~~~~~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.cpp:39:36: error: class ‘vr::DriverContext’ does not have any field named ‘m_pVRResources’
       m_pVRDriverManager(nullptr), m_pVRResources(nullptr) {}
                                    ^~~~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.cpp: In constructor ‘vr::DriverContext::DriverContext(vr::ServerDriverHost*, vr::Settings*, vr::DriverLog*, vr::Properties*, vr::DriverManager*, vr::Resources*)’:
/home/george/OSVR-Vive/DriverContext.cpp:48:7: error: class ‘vr::DriverContext’ does not have any field named ‘m_pVRDriverManager’
       m_pVRDriverManager(driverManager), m_pVRResources(resources) {}
       ^~~~~~~~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.cpp:48:42: error: class ‘vr::DriverContext’ does not have any field named ‘m_pVRResources’
       m_pVRDriverManager(driverManager), m_pVRResources(resources) {}
                                          ^~~~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.cpp: In member function ‘virtual void* vr::DriverContext::GetGenericInterface(const char*, vr::EVRInitError*)’:
/home/george/OSVR-Vive/DriverContext.cpp:62:41: error: ‘IVRDriverManager_Version’ was not declared in this scope
     } else if (interfaceVersion.compare(IVRDriverManager_Version) == 0) {
                                         ^~~~~~~~~~~~~~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.cpp:63:16: error: ‘m_pVRDriverManager’ was not declared in this scope
         return m_pVRDriverManager;
                ^~~~~~~~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.cpp:64:41: error: ‘IVRResources_Version’ was not declared in this scope
     } else if (interfaceVersion.compare(IVRResources_Version) == 0) {
                                         ^~~~~~~~~~~~~~~~~~~~
/home/george/OSVR-Vive/DriverContext.cpp:65:16: error: ‘m_pVRResources’ was not declared in this scope
         return m_pVRResources;
                ^~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/ViveLoaderLib.dir/build.make:87: CMakeFiles/ViveLoaderLib.dir/DriverContext.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:105: CMakeFiles/ViveLoaderLib.dir/all] Error 2
make: *** [Makefile:128: all] Error 2

George Frolov · Answer 1 · Sat Jun 17 2017 02:57:07 GMT+0800 (China Standard Time)

Hi George,
I think that submodules have not updated after you pulled the openvr108 branch. The errors are indicating that it cannot find code that is present in the latest OpenVR SDK.
Please run git submodule update --recursive and give it one more try.

George Singer · Answer 2 · Sat Jun 17 2017 04:03:07 GMT+0800 (China Standard Time)

Yes -- that worked.

Running the newly compiled ViveDisplayExtractor yields [DisplayExtractor] Error in first-stage Vive driver startup. Exiting. I'm re-downloading SteamVR though which I think might fix this.

George Singer · Answer 3 · Sat Jun 17 2017 22:36:38 GMT+0800 (China Standard Time)

Update: Still Unable to Use #32 on Linux

Running Arch Linux (with SteamVR fully updated and launchable), I successfully compiled #32, and then symlinked /usr/lib/osvr-plugins-0/com_osvr_Vive.so to the com_osvr_Vive.so generated from the build:

$ cd /usr/lib/osvr-plugins0
$ ls -l com_osvr_Vive.so
com_osvr_Vive.so -> /home/george/OSVR-Vive/build/lib/osvr-plugins-0/com_osvr_Vive.so

however, I am unable to get ViveDisplayExtractor to work:

$ ViveDisplayExtractor
[DisplayExtractor] Error in first-stage Vive driver startup. Exiting

After ignoring this and assembling an OSVR config from the OSVR-Vive repo, I get a "could not open driver" message:

$ sudo osvr_server default_config_from_repo.json 
June 17 10:42:01.619 info [OSVR]: Logging for /usr/bin/osvr_server
June 17 10:42:01.619 info [OSVR Server]: Using config file default_config_from_repo.json from command line argument.
June 17 10:42:01.619 info [OSVR Server]: Attempting to load config file 'default_config_from_repo.json'.
June 17 10:42:01.619 info [OSVR Server]: Constructing server as configured...
June 17 10:42:01.619 info [OSVR Server]: Loading auto-loadable plugins...
June 17 10:42:01.664 info [OSVR Server]: Loading plugins...
June 17 10:42:01.664 info [OSVR Server]: Instantiating configured drivers...
June 17 10:42:01.664 info [OSVR Server]: Display descriptor found and parsed from config file.
June 17 10:42:01.664 info [OSVR Server]: RenderManager config found and parsed from the config file.
June 17 10:42:01.664 info [OSVR Server]: Triggering automatic hardware detection...
June 17 10:42:01.664 info [OSVR Server]: Registering shutdown handler...
June 17 10:42:01.664 info [OSVR Server]: Starting server mainloop: OSVR Server is ready to go!
June 17 10:42:01.664 info [OSVR Server]: Performing hardware auto-detection.
June 17 10:42:01.701 info [OSVR-Vive]: Could not open driver.
June 17 10:42:01.701 info [OSVR Server]: Sent path tree to clients.

# after launching RenderManagerOpenGLCoreExample:

vrpn_Endpoint::getOneTCPMessage:  Can't read header (this is normal when a connection is dropped)
vrpn: TCP handling failed, dropping connection (this is normal when a connection is dropped)

and then am unable to launch RenderManagerOpenGLCoreExample:

$ RenderManagerOpenGLCoreExample 
June 17 10:42:43.504 info [OSVR]: Logging for /usr/bin/RenderManagerOpenGLCoreExample
June 17 10:42:43.504 info [OSVR: com.osvr.renderManager.openGLExample]: OSVR client context initialized for com.osvr.renderManager.openGLExample
June 17 10:42:43.505 info [OSVR: com.osvr.renderManager.openGLExample]: Got connection to main OSVR server
June 17 10:42:43.540 info [OSVR: com.osvr.renderManager.openGLExample]: Connected 0 of 0 unconnected paths successfully
June 17 10:42:43.541 info [OSVR: com.osvr.renderManager.openGLExample]: Connection process took 36ms: have connection to server, have path tree
June 17 10:42:43.541 info [OSVR]: /tmp/yaourt-tmp-george/aur-osvr-core-git/src/osvr-core/src/osvr/Common/ClientInterface.cpp:38: Interface initialized for /controller/left/1
June 17 10:42:43.542 info [OSVR: com.osvr.renderManager.openGLExample]: Could not resolve source for /controller/left/1
June 17 10:42:43.542 info [OSVR]: /tmp/yaourt-tmp-george/aur-osvr-core-git/src/osvr-core/src/osvr/Common/ClientInterface.cpp:38: Interface initialized for /controller/right/1
June 17 10:42:43.542 info [OSVR: com.osvr.renderManager.openGLExample]: Could not resolve source for /controller/right/1
June 17 10:42:43.542 info [OSVR]: /tmp/yaourt-tmp-george/aur-osvr-core-git/src/osvr-core/src/osvr/Common/ClientInterface.cpp:38: Interface initialized for /me/head
June 17 10:42:43.542 info [OSVR: com.osvr.renderManager.openGLExample]: Could not resolve source for /me/head
June 17 10:42:43.542 info [OSVR]: /tmp/yaourt-tmp-george/aur-osvr-core-git/src/osvr-core/src/osvr/Common/ClientInterface.cpp:38: Interface initialized for /me/head
June 17 10:42:43.542 info [OSVR]: /tmp/yaourt-tmp-george/aur-osvr-core-git/src/osvr-core/src/osvr/Common/ClientInterface.cpp:38: Interface initialized for /me/head
June 17 10:42:43.542 info [OSVR]: /tmp/yaourt-tmp-george/aur-osvr-core-git/src/osvr-core/src/osvr/Client/DisplayConfig.cpp:195: Display: HTC Vive/Vive PRE [Display descriptor note: This is a sample descriptor file only - please follow the instructions to use the ViveDisplayExtractor to generate a correct one for your device!]
June 17 10:42:43.542 info [OSVR]: /tmp/yaourt-tmp-george/aur-osvr-core-git/src/osvr-core/src/osvr/ClientKit/DisplayC.cpp:47: Created an OSVR_DisplayConfigObject!
June 17 10:42:43.742 error [createRenderManager]: Got Display info from server (ignore earlier errors that occured while we were waiting to connect)
OSVRDisplayConfiguration::parse(): Using rgb point sample distortion.
OSVRDisplayConfiguration::parse(): Reading and parsing JSON in external RGB point samples file /usr/share/osvrcore/displays/HTC_Vive_meshdata.json
OSVRDisplayConfiguration::parse(): File read and JSON parse complete.
June 17 10:42:43.750 info [createRenderManager]: Display descriptor reports vendor as HTC
June 17 10:42:43.750 info [createRenderManager]: Adding direct mode candidate PNPID HVR described as HTC
June 17 10:42:43.750 error [createRenderManager]: OpenGL/Direct3D Interop not compiled in
Could not create RenderManager
June 17 10:42:43.750 info [OSVR: com.osvr.renderManager.openGLExample]: OSVR client context shut down for com.osvr.renderManager.openGLExample
June 17 10:42:43.750 info [OSVR]: /tmp/yaourt-tmp-george/aur-osvr-core-git/src/osvr-core/src/osvr/ClientKit/DisplayC.cpp:50: OSVR_DisplayConfigObject destructor

Finally: launching OSVRTrackerView shows an empty 3-space grid (no headset or controllers picked up).

Tom Langwaldt · Answer 4 · Sat Jun 17 2017 23:13:41 GMT+0800 (China Standard Time)

I wonder if our issues have the same origin, my Server logs the following:

June 17 17:12:03.212 info [OSVR Server]: Using default config file - pass a filename on the command line to use a different one.
June 17 17:12:03.212 info [OSVR Server]: Using config file 'osvr_server_config.json'.
June 17 17:12:03.212 info [OSVR Server]: Constructing server as configured...
June 17 17:12:03.215 info [OSVR Server]: Loading auto-loadable plugins...
June 17 17:12:03.224 info [OSVR Server]: Loading plugins...
June 17 17:12:03.224 info [OSVR Server]: Instantiating configured drivers...
June 17 17:12:03.225 info [OSVR Server]: Added device: org_osvr_filter_videoimufusion/HeadFusion
June 17 17:12:03.225 info [OSVR: org.osvr.analysisplugin]: OSVR client context initialized for org.osvr.analysisplugin
June 17 17:12:03.225 info [OSVR]: Z:\j\workspace\OSVR-Core-Build-Win\BIT\64\TRACING\OFF\VS\12\host\windows\src\osvr\Common\ClientInterface.cpp:38: Interface initialized for /com_osvr_Multiserver/OSVRHackerDevKitPrediction0/semantic/hmd
June 17 17:12:03.225 info [OSVR]: Z:\j\workspace\OSVR-Core-Build-Win\BIT\64\TRACING\OFF\VS\12\host\windows\src\osvr\Common\ClientInterface.cpp:38: Interface initialized for /com_osvr_VideoBasedHMDTracker/TrackedCamera0_0/semantic/hmd/front
June 17 17:12:03.225 info [OSVR Server]: Successes:
June 17 17:12:03.225 info [OSVR Server]:  - com_osvr_VideoBasedHMDTracker/VideoBasedHMDTracker
June 17 17:12:03.225 info [OSVR Server]:  - org_osvr_filter_videoimufusion/VideoIMUFusion
June 17 17:12:03.225 info [OSVR Server]: Aliases found and parsed from config file.
June 17 17:12:03.226 info [OSVR Server]: Display descriptor found and parsed from config file.
June 17 17:12:03.226 info [OSVR Server]: RenderManager config found and parsed from the config file.
June 17 17:12:03.226 info [OSVR Server]: Triggering automatic hardware detection...
June 17 17:12:03.226 info [OSVR Server]: Registering shutdown handler...
June 17 17:12:03.226 info [OSVR Server]: Starting server mainloop: OSVR Server is ready to go!
June 17 17:12:03.226 info [OSVR Server]: Performing hardware auto-detection.

Video-based tracker: Could not open the tracking camera. If you intend to use it, make sure that all cables to it are plugged in firmly.
Video-based tracker: Windows users may need to exit other camera-using applications or activities until after the tracking camera is turned on by this plugin. (This is the most common cause of messages regarding the 'filter graph')

Still, same error as yours

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

Christoph Haag · Answer 5 · Sat Jun 17 2017 23:33:49 GMT+0800 (China Standard Time)

@georgewsinger

June 17 10:42:43.750 error [createRenderManager]: OpenGL/Direct3D Interop not compiled in

You're probably using a rendermanager config with direct mode enabled. In osvr_server_config.vive.sample.json you can just use the standard extended mode config:

"renderManagerConfig": "/usr/share/osvrcore/sample-configs/renderManager.extended.landscape.json"

George Singer · Answer 6 · Sat Jun 17 2017 23:36:59 GMT+0800 (China Standard Time)

@ChristophHaag I can confirm changing to extended mode allows, i.e., RenderManagerOpenGLCoreExample to launch, however there is no tracking present (neither with the headset nor the Vive controllers). In addition, OSVRTrackerView continues to show no tracked objects (neither HMDs nor controllers).

Christoph Haag · Answer 7 · Sat Jun 17 2017 23:42:20 GMT+0800 (China Standard Time)

Yes, your vive plugin prints

June 17 10:42:01.701 info [OSVR-Vive]: Could not open driver.

It should do this before the block that prints "Could not open driver":

if (vive.foundDriver()) {
    std::cout << PREFIX << "Found the Vive driver at "
              << vive.getDriverFileLocation() << std::endl;
}

so for some reason it doesn't find the Vive driver. For me it prints

June 17 17:39:34.561 info [OSVR-Vive]: Found the Vive driver at /home/chris/.local/share/Steam/SteamApps/common/SteamVR/drivers/lighthouse/bin/linux64/driver_lighthouse.so

It's probably looking in the path specified in ~/.openvr/openvrpaths.vrpath

George Singer · Answer 8 · Sat Jun 17 2017 23:45:52 GMT+0800 (China Standard Time)

@ChristophHaag : Can you post the contents of your ~/.openvr/openvrpaths.vrpath for comparison?

Here is mine:

{
	"runtime" : [ "/home/george/.local/share/Steam/SteamApps/common/SteamVR" ],
	"config" : [ "/home/george/.local/share/Steam/config" ],
	"log" : [ "/home/george/.local/share/Steam/logs" ]
}

Christoph Haag · Answer 9 · Sun Jun 18 2017 00:00:02 GMT+0800 (China Standard Time)

It's this one: https://haagch.frickel.club/files/openvrpaths.vrpath.txt, looks just like yours.

If you have the file ~/.local/share/Steam/SteamApps/common/SteamVR/drivers/lighthouse/bin/linux64/driver_lighthouse.so and it looks okay then I don't know what the problem is.

George Singer · Answer 10 · Sun Jun 18 2017 00:02:18 GMT+0800 (China Standard Time)

I can confirm that I also have ~/.local/share/Steam/SteamApps/common/SteamVR/drivers/lighthouse/bin/linux64/driver_lighthouse.so.

Weird.

George Singer · Answer 11 · Sun Jun 18 2017 00:50:09 GMT+0800 (China Standard Time)

I also found ./home/george/.config/openvr/openvrpaths.vrpath that was somehow generated on my system (I wonder which one is read when launching osvr_server?); it has the following contents:

{
   "config" : [ "/home/george/.local/share/Steam/config" ],
   "external_drivers" : null,
   "jsonid" : "vrpathreg",
   "log" : [ "/home/george/.local/share/Steam/logs" ],
   "runtime" : [
      "/home/george/steamcmd/steamapps/common/SteamVR/",
      "/home/george/steamcmd/steamapps/common/SteamVR",
      "/home/george/.local/share/Steam/steamapps/common/SteamVR/",
      "/home/george/.local/share/Steam/steamapps/common/SteamVR"
   ],
   "version" : 1
}

However, after changing this to the usual contents reported above:

{
	"runtime" : [ "/home/george/.local/share/Steam/SteamApps/common/SteamVR" ],
	"config" : [ "/home/george/.local/share/Steam/config" ],
	"log" : [ "/home/george/.local/share/Steam/logs" ]
}

...the original "Could not open driver." error persists.

Christoph Haag · Answer 12 · Sun Jun 18 2017 01:04:47 GMT+0800 (China Standard Time)

I was hoping someone from OSVR would know more about this. It looks like something there is going wrong and I would probably start investigating at these lines... https://github.com/OSVR/OSVR-Vive/blob/master/FindDriver.cpp#L217

George Frolov · Answer 13 · Tue Jun 20 2017 05:32:26 GMT+0800 (China Standard Time)

@georgewsinger ,
Hmm, based on the error, it looks like there could be multiple things that are going wrong:

Config dir is not found
Driver file and/or driver directory is not found.
However since you included that you have the driver file itself, then it could be a mix up due to an environment variable.
What does your $HOME variable point to ? OSVR-Vive will use $HOME variable if it's available, but if it's not then it will use ~/.openvr/openvrpaths.vrpath, so I'd first check on that.
If that looks good, then check if /home/george/.local/share/Steam/config exists.

George Singer · Answer 14 · Wed Jun 21 2017 05:35:39 GMT+0800 (China Standard Time)

My $HOME directory is set to /home/george. So it seems that $HOME/.openvr/openvrpaths.vrpath is the same as ~/.openvr/openvrpaths.vrpath; its contents is

{
	"runtime" : [ "/home/george/.local/share/Steam/SteamApps/common/SteamVR" ],
	"config" : [ "/home/george/.local/share/Steam/config" ],
	"log" : [ "/home/george/.local/share/Steam/logs" ]
}

I can confirm that /home/george/.local/share/Steam/config exists:

$ tree /home/george/.local/share/Steam/config
/home/george/.local/share/Steam/config
├── appconfig.json
├── avatarcache
│   └── 76561198322831683.png
├── chaperone_info.vrchap
├── config.vdf
├── DialogConfig.vdf
├── htmlcache
│   ├── Cache
│   │   ├── <truncated>
│   │   └── index
│   ├── Cookies
│   ├── Cookies-journal
│   └── Visited Links
├── lighthouse
│   ├── lhr-9d8ea690
│   │   ├── config.json
│   │   └── userdata
│   │       ├── Green_46GA165G007128_mura_analyzes.mc
│   │       └── Green_46HA165J006869_mura_analyzes.mc
│   ├── lhr-f7fedd45
│   │   └── config.json
│   ├── lhr-ff421d45
│   │   └── config.json
│   └── lighthousedb.json
├── loginusers.vdf
├── oculus
├── oculus_legacy
├── steamapps.vrmanifest
├── steamvr.vrsettings
├── vrappconfig
│   ├── openvr.tool.steamvr_environments.vrappconfig
│   ├── openvr.tool.steamvr_room_setup.vrappconfig
│   └── openvr.tool.steamvr_tutorial.vrappconfig
└── widevine
    ├── libwidevinecdmadapter.so
    ├── libwidevinecdm.so
    ├── LICENSE.txt
    └── manifest.json

Is there something else I could be missing?

George Singer · Answer 15 · Thu Jun 22 2017 06:47:44 GMT+0800 (China Standard Time)

UPDATE: I've done a little bit of poking into the source code to try to figure out what's causing the driver to fail to be found. The problem with driver initialization can be superficially traced to DriverWrapper.h:

bool haveDriverLoaded() const {
		// only one of these pointers will ever be initialized at a time,
		// since we move from loader_ to initialize serverDeviceProvider_

		// loader_ has an explicit operator bool to check its success, hence
		// the longer check.
		return (static_cast<bool>(loader_) &&                //evalutes as "0" when printed
			   static_cast<bool>(*loader_)) ||
			   static_cast<bool>(serverDeviceProvider_); //evaluates as "0" when printed
}

As the comments indicate, both static_cast<bool>(loader_) and static_cast<bool>(serverDeviceProvider_) evaluate to 0 when printed. From there it's more opaque what's causing this. While I'm no C++ expert, I'm assuming this indicates an upstream failure having to do with loader_ and/or serverDeviceProvider_ (i.e., these pointers aren't pointing to anything).

I wonder if there's a way to print to the console what OSVR-Vive thinks my driver directory is?

George Singer · Answer 16 · Sat Jun 24 2017 03:49:09 GMT+0800 (China Standard Time)

Thanks to @ChristophHaag helping me debug my system, it turns out that

$ cd /home/george/.local/share/Steam
$ ln -s steamapps SteamApps

solved the issue. That is, OSVR-Vive is expecting a folder called SteamApps, and yet on my system it was somehow being generated by steam as steamapps? Creating this symlink allows OSVR-Vive to successfully find the driver.

End result: I can now launch OSVR-Vive in direct mode and run OSVRTrackerViewer, which shows HTC Vive controllers + Headset being tracked. Running in extended mode yields the server error:

June 23 15:50:49.292 info [Settings]: GetBool doesn't contain the settingKey: fakeDigitalTrigger

and then causes a seg fault.

In direct mode, I still cannot launch, i.e., RenderManagerOpenGLCoreExample without getting the error:

June 23 15:48:37.097 error [createRenderManager]: OpenGL/Direct3D Interop not compiled in
Could not create RenderManager

So there's no way for me to run a test app with OSVR-Vive yet.

Christoph Haag · Answer 17 · Sat Jun 24 2017 08:10:27 GMT+0800 (China Standard Time)

@georgewsinger
Well.. in #33 (comment) you said your steam-generated openvrpaths.vrpath said

"runtime" : [
   "/home/george/steamcmd/steamapps/common/SteamVR/",
   "/home/george/steamcmd/steamapps/common/SteamVR",
   "/home/george/.local/share/Steam/steamapps/common/SteamVR/",
   "/home/george/.local/share/Steam/steamapps/common/SteamVR"
],

which apparently didn't work, so you changed it to

"runtime" : [ "/home/george/.local/share/Steam/SteamApps/common/SteamVR" ],

If you remove the symlink and try it with

"runtime" : [ "/home/george/.local/share/Steam/steamapps/common/SteamVR" ],

it could work too..

Anyway, #33 (comment) was probably wrong. Those case errors are insidious because of how easily you can fail to see them...

To any of the developers: It would be great if OSVR-Vive could output some debug info here, e.g. the file name it is trying to open and an error message when it fails.

George Singer · Answer 18 · Sat Jun 24 2017 08:50:18 GMT+0800 (China Standard Time)

@ChristophHaag: You're right. The issue was a case error with my openvrpaths.vrpath the whole time.

George Frolov · Answer 19 · Mon Dec 11 2017 23:36:20 GMT+0800 (China Standard Time)

@georgewsinger
Do you still have this problem on Linux with the latest version or we can resolve the issue ?