kisak-valve
commented
6 months ago Open DevilishSpirits opened 6 months ago
kisak-valve
commented
6 months ago 
DevilishSpirits
commented
6 months ago In reply to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/698#issuecomment-2105071145 :
Headset has no video (just black) once connected.
In my situation, there is not even a connection as the ALVR plugin won't get loaded at all.
On Steam community, ttimo mentioned possible sandboxing issues that made /usr/lib/steamvr/alvr/ inaccessible from SteamVR container. On the linked report where ALVR plugin do get loaded, the OP used the ".tar.gz" method that might have been extracted somewhere the SteamVR runtime is allowed to access 🤔.
DevilishSpirits
commented
6 months ago So now this problem is happening on the previous channel, I was able to start ALVR with the ".tar.gz" method, so it seems that whatever sandboxing Steam does, it interfere with normal system operations. Unfortunately I failed to find any documentation about Steam sandboxing.
So is there someone who know how to whitelist multiple system path (ALVR need some shared libraries too) ?
Or to run SteamVR unsandboxed until this bug get fixed ?
Delkarix
commented
6 months ago Had the same problem. Used the ".tar.gz" method, and while ALVR successfully launched and connected, the headset only displayed a black screen. I did, however, try to manually downgrade to SteamVR Beta 2.4.4 (using steamcmd download_depot command) in an attempt to see if an older version would work. This version did not work at first and only launched (with the black screen) using the ".tar.gz" method. I'm gonna play around with this a little more and report any other findings.
Edit: Rolled back to 2.3.1. Same issue, "Skipping external driver..." and black screen with .tar.gz
DanaGoyette
commented
6 months ago Copying my comment from ALVR: https://github.com/alvr-org/ALVR/issues/2124
By looking around in ls -la /proc/$(pidof vrserver)/root/ (which seems to actually show the process's root, not the system root), I was able to see that the /usr/lib64/alvr directory isn't there.
But I also found out that there's a path /run/host that exposes the host root filesystem.
By editing ~/.config/openvr/openvrpaths.vrpath to mention /run/host/usr/lib64/alvr instead of /usr/lib64/alvr, I was able to get the headset detected. I also had to tell ALVR launcher to stop altering that file, via the "Extra" settings.
Is there a reason SteamVR isn't exposing the configured path in its pressure-vessel thing? I'm running it on Debian 12 (Proxmox, actually).
Side note: that pressure-vessel is also missing a fair number of other things that exist on the machine outside the container. Perhaps it's just broken on my machine? Here are a few I collected from Steam's logs and its console output:
sh: 1: xdg-icon-resource: not found
sh: 1: xdg-mime: not found
/home/dana/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/restarthelper: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
QLibraryPrivate::loadPlugin failed on "/home/dana/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/qt/plugins/platforms/libqxcb.so" : "Cannot load library /home/dana/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/qt/plugins/platforms/libqxcb.so: (/home/dana/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/qt/plugins/platforms/../../lib/libQt5XcbQpa.so.5: undefined symbol: _ZN11QFontEngine14bitmapForGlyphEj6QFixedRK10QTransform)"
GrigoriyPeters
commented
6 months ago So now this problem is happening on the
previouschannel, I was able to start ALVR with the ".tar.gz" method, so it seems that whatever sandboxing Steam does, it interfere with normal system operations. Unfortunately I failed to find any documentation about Steam sandboxing. So is there someone who know how to whitelist multiple system path (ALVR need some shared libraries too) ? Or to run SteamVR unsandboxed until this bug get fixed ?
I can confirm this issue. Yesterday I was able to play VR with the latest ALVR and 'previous' SteamVR beta, and now I cant. SteamVR just won't register the ALVR driver.
270899colin
commented
6 months ago Same issue with Monado, vrpathreg.sh lists the driver under external drivers but I get the same "Skipping external driver" message in the log when trying to run SteamVR
GrigoriyPeters
commented
6 months ago As was mentioned in ALVR issue https://github.com/alvr-org/ALVR/issues/2112#issuecomment-2115578187 Now ALVR 20.8.1 works with SteamVR 2.4.4 using https://github.com/Scrumplex/Steam-Play-None
Delkarix
commented
6 months ago As was mentioned in ALVR issue alvr-org/ALVR#2112 (comment) Now ALVR 20.8.1 works with SteamVR 2.4.4 using https://github.com/Scrumplex/Steam-Play-None
Tried this using the Steam-Play-None manual install. Uninstalled and reinstalled SteamVR multiple times and launched it a few times prior to starting ALVR in order to ensure proper config generation for ALVR. However, SteamVR would launch and give an error message ("SteamVR failed to initialize for unknown reasons. (Error: Not initialized (109) (109))") and give the "headset not detected" error. Upon launching, ALVR would detect SteamVR and SteamVR would launch successfully, but on the headset the view would appear black, just like with the ".tar.gz" method, and a message would appear over the vrmonitor saying "Failed to connect headset display. Your headset might not be connected, or your desktop environment might not support VR.".
sol8712
commented
6 months ago Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/698#issuecomment-2118583550
Are you using steam-native and have steamvr set to previous branch? Also try using the latest alvr-nightly.
Delkarix
commented
6 months ago Replying to #698 (comment)
Are you using steam-native and have steamvr set to previous branch? Also try using the latest alvr-nightly.
SteamVR was indeed set to previous branch, wasn't using alvr-nightly. I was using steam-runtime rather than steam-native. After switching to steam-native, a new prompt came up stating that SteamVR required superuser access to install, just like how it normally acts upon first installation. However, upon clicking "okay", it cancels and states that the setup was incomplete and some features would be missing. I (somewhat) solved this issue using a solution described in issue #234, which fixed the popup, however the aforementioned "Failed to connect headset display. Your headset might not be connected, or your desktop environment might not support VR" and Error 109 errors persisted. I'll experiment more tomorrow, including switching my WM and changing to alvr-nightly. The WM shouldn't be a problem (I'm using AwesomeWM and have been for around a year now with little to no problems with regards to Steam or SteamVR) but I'll switch to something like KDE or i3wm in the mean time just to be safe (I know i3wm at least would work and KDE is generally stress-tested enough to (probably) not encounter too many bugs). I'm a little short on time right now though, so I can't get to it all immediately.
Edit: I tried alvr-nightly v21.0.0. Same exact issues: black screen, Error 109, failed to connect headset display. Haven't changed WM yet, but I'm starting to suspect that there may be a disconnect between how SteamVR is set up and how ALVR can launch it.
astroty
commented
6 months ago Hello, I'm using KDE right now (Archlinux) and managed to get it working by doing the following: Launch ALVR (I'm using a git compiled build from the AUR but I don't know if this step is essential) Make sure to register the ALVR Driver if it isn't yet Go to the SteamVR folder, enter the bin folder (Steam is already open) open the terminal on that folder and manually execute vrmonitor (./vrmonitor.sh) This makes SteamVR work for me
ZhenyaPav
commented
6 months ago (Steam is already open) open the terminal on that folder and manually execute vrmonitor (./vrmonitor.sh) Can confirm that it works on the non *-git version of alvr as well
Delkarix
commented
6 months ago Hello, I'm using KDE right now (Archlinux) and managed to get it working by doing the following: Launch ALVR (I'm using a git compiled build from the AUR but I don't know if this step is essential) Make sure to register the ALVR Driver if it isn't yet Go to the SteamVR folder, enter the bin folder (Steam is already open) open the terminal on that folder and manually execute vrmonitor (./vrmonitor.sh) This makes SteamVR work for me
Wow, this actually works! No errors or anything and I am seeing the SteamVR home without a black screen. Thank you!
NOTE: If SteamVR shows "headset not detected" or if you change any settings in ALVR, you'll have to launch SteamVR from ALVR (while it's open) and then close SteamVR, and then reopen it from the terminal.
vorador
commented
6 months ago Hello, I'm using KDE right now (Archlinux) and managed to get it working by doing the following: Launch ALVR (I'm using a git compiled build from the AUR but I don't know if this step is essential) Make sure to register the ALVR Driver if it isn't yet Go to the SteamVR folder, enter the bin folder (Steam is already open) open the terminal on that folder and manually execute vrmonitor (./vrmonitor.sh) This makes SteamVR work for me
This works! With the current SteamVR version and ALVR 20.8.1. No need to select beta/previous version, no need to use steam-play-none.
man-nicholl
commented
6 months ago The workaround does indeed work (hopefully it doesn't break in the future). To get it to work without doing the "launch SteamVR from ALVR" then "launch vrmonitor.sh quickly from terminal" dance, set this as your SteamVR launch options: WAYLAND_DISPLAY='' ~/.local/share/Steam/steamapps/common/SteamVR/bin/vrmonitor.sh %command% The WAYLAND_DISPLAY='' part might not be needed anymore, but I keep it there just in case. Having %command% at the end actually passes the SteamVR executable to the vrmonitor.sh, but vrmonitor.sh doesn't actually do anything with it; %command% is just needed somewhere in the launch options otherwise it would execute the normal SteamVR executable instead of the vrmonitor.sh script.
alpnist
commented
6 months ago Can verify this works with XFCE and non wayland. Set the launch option for SteamVR
"~/.steam/debian-installation/steamapps/common/SteamVR/bin/vrmonitor.sh" %command%
No more previous version No more Steam-Play-None
Meister1593
commented
6 months ago Can verify this works with XFCE and non wayland. Set the launch option for SteamVR
"~/.steam/debian-installation/steamapps/common/SteamVR/bin/vrmonitor.sh" %command%
No more previous version No more Steam-Play-None
Can confirm, even beta works
With small correction, it needs to needed to be absolute path and it's deb-package specific path, on different distros it's just /home/user/.steam/steam...
Meister1593
commented
6 months ago On arch:
~/.steam/steam/steamapps/common/SteamVR/bin/vrmonitor.sh %command% worked
Without double quotes
0chroma
commented
2 months ago For anyone using flatpak + gnome wayland, these launch options worked for me:
WAYLAND_DISPLAY='' /var/data/Steam/steamapps/common/SteamVR/bin/vrmonitor.sh %command%
I initially reported this bug in SteamVR community : https://steamcommunity.com/app/250820/discussions/3/4364628251566133932/.
Describe the bug SteamVR will not load the ALVR plugin which is installed in /usr/lib/steamvr/alvr, this is a normal directory, not a mount point or symlink.
The following line appear 3 times in SteamVR web console and there is no other mention of ALVR :
To Reproduce
You don't need a headset with ALVR client to reproduce the bug.
Expected behavior ALVR plugin is loaded and the ALVR dashboard report a successful connection to SteamVR.
System Information (please complete the following information): Please use the latest Steam beta client and SteamVR beta for your bug reports!
Additional context I successfully started once SteamVR while stracing the vrstartup binary from my console but I cannot reproduce this again. This problem occur in the standard, "beta" but not the "previous" release channel I currently rely to.