Open georgewsinger opened 7 years ago
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.
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.
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).
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.
@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"
@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).
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
@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" ]
}
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.
I can confirm that I also have ~/.local/share/Steam/SteamApps/common/SteamVR/drivers/lighthouse/bin/linux64/driver_lighthouse.so
.
Weird.
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.
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
@georgewsinger , Hmm, based on the error, it looks like there could be multiple things that are going wrong:
$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.$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" ]
}
/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?
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?
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.
@georgewsinger Well.. in https://github.com/OSVR/OSVR-Vive/issues/33#issuecomment-309226384 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, https://github.com/OSVR/OSVR-Vive/issues/33#issuecomment-309223629 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.
@ChristophHaag: You're right. The issue was a case error with my openvrpaths.vrpath
the whole time.
@georgewsinger Do you still have this problem on Linux with the latest version or we can resolve the issue ?
I'm running Arch Linux:
This yields the following build error: