Nixpkgs: SteamVR fails to load into games

Created on 21 Oct 2019  路  15Comments  路  Source: NixOS/nixpkgs

Describe the bug
SteamVR fails to load into games due to failing get superuser access. Manually setting the permissions it expects also leads to unexpected behaviour.

To Reproduce
Steps to reproduce the behavior:

  1. Install a fresh version of Steam and SteamVR, I'm using an HTC Vive
  2. When trying to launch, it will open a zenity instance asking for superuser permissions
  3. Choosing either option will yield an error saying setup is incomplete, check a log.
  4. The log reads "Error: setcap of vrcompositor-launcher failed.", the setcap is trying to set cap_sys_nice

Expected behavior
I'd expect to install steamvr, give it the permissions it asks for, either manually or through the zenity dialogue, then be able to play supported games.

Screenshots
fresh install
perms set manually

Additional context
Using the troubleshooting steps from here yielded no results.
Additionally, overriding the steam package to be build with libcap did not change anything.
hardware.steam-hardware.enable = true; is set in my config.nix.
If you continue after it fails to get access, games will load, but accept no input and the HMD will be stuck at the loading screen instead.
When the permissions it wants were manually set the HMD did not show any output, and games would not load.
Launching steam via terminal and reading the output shows the error is thrown in ~/.local/share/Steam/steamapps/common/SteamVR/bin/vrstartup.sh
Here's the steam console output with the perms set
and without

Metadata

  • system: "x86_64-linux"
  • host os: Linux 4.19.79, NixOS, 20.03pre196836.1c40ee6fc44 (Markhor)
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.3.1
  • channels(root): "home-manager, nixos-20.03pre196836.1c40ee6fc44"
  • channels(kristian): "home-manager"
  • nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:nixpkgs.steam
# a list of nixos modules affected by the problem
module:
bug steam

Most helpful comment

This issue has gotten a bit bloated and most of the discussion has nothing to do with OP's problem, so I've created two new issues (see links above). One for the popup issue and one for the vrcompositor-launcher issue.

In the latter I have also made progress investigating why it works on other distros but not NixOS.

All 15 comments

I'm able to reproduce the issue with a Valve Index HMD.

Error: setcap of vrcompositor-launcher failed.

I see the SteamVR Home and i can launch a game, but the game is not streamed to the HMD.

gamestream/gamestreamsystem.cpp (829) : Assertion Failed: pState->m_nProcess == nProcess
gamestream/gamestreamsystem.cpp (829) : Assertion Failed: pState->m_nProcess == nProcess
gamestream/gamestreamsystem.cpp (829) : Assertion Failed: pState->m_nProcess == nProcess
 SDL_GetWindowWMInfo failed
 SDL_GetWindowWMInfo failedMain.cpp (332) : Assertion Failed: Fatal Error:  SDL_GetWindowWMInfo failed
Main.cpp (332) : Assertion Failed: Fatal Error:  SDL_GetWindowWMInfo failed
Installing breakpad exception handler for appid(steam)/version(1573019481)
crash_20191113104336_120.dmp[9621]: Uploading dump (out-of-process)
/tmp/dumps/crash_20191113104336_120.dmp
crash_20191113104336_120.dmp[9621]: Finished uploading minidump (out-of-process): success = yes
crash_20191113104336_120.dmp[9621]: response: CrashID=bp-94dc8d4c-8896-4687-9e72-8919b2191113
crash_20191113104336_120.dmp[9621]: file ''/tmp/dumps/crash_20191113104336_120.dmp'', upload yes: ''CrashID=bp-94dc8d4c-8896-4687-9e72-8919b2191113''
Exiting on SPEW_ABORT
VR Server (v1573603529)

See the full log: steamlog.txt


Running Steam on nixos 19.09.1208.ef8c34c4721

Can also reproduce with a Vive Pro on my system. I tried moving Steam from my home-manager packages to system packages (fixes some issues with Steam URI stuff it seems), but didn't change anything. I also attempted to setcap the file myself but hit a library error, so tried wrapping the file in a script with LD_PRELOAD, but that failed with the "Something is wrong" error. Tried adding libcap and libcap.lib to Steam's extraLibraries but as mentioned above did not help.

tl;dr I couldn't find any workarounds at all, or system (mis-)configurations causing it.

If anybody cannot reproduce this but has any ideas I'm happy to try poking around with things some more, and potentially working into a true fix.

Here's an extremely hack-ish workaround. I've tested this as working with a couple of VR games that use Proton (VTOLVR and Thrill of the Fight).

Run:

sed -i 's/LD_LIBRARY_PATH=/                /g' $HOME/.local/share/Steam/steamapps/common/SteamVR/bin/vrclient.so
sed -i 's/LD_LIBRARY_PATH=/                /g' $HOME/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so

(getting the correct number of spaces in the above command is important--and this will break every time SteamVR updates)

Partial explanation:
The vrclient.so files have some strings such as:
STEAM_RUNTIME=0 LD_LIBRARY_PATH= lsusb -d %x:%x > /dev/null
STEAM_RUNTIME= LD_LIBRARY_PATH= QT_PLUGIN_PATH= pidof
and apparently their overriding the LD_LIBRARY_PATH like this seems to break things.
I don't have the logs conveniently available, but I recall seeing error messages about missing libGL, which is normally passed in to the steam environment with LD_LIBRARY_PATH pointing to /run/opengl-driver/lib.
It doesn't make a whole lot of sense why programs like lsusb or pidof would be complaining about missing libGL--but here we are.

The issue with setcap described in the earlier comments is still unresolved, however, but is not necessary in order to run some games. Presumably, we'd get better performance if that was fixed.

That fix works perfectly for me, thanks! From what I could find, setcap is only necessary to enable async reprojection, which seems relatively new to SteamVR Linux and only supports AMD GPUs (which I unfortunately do not have right now anyway).

Would a slightly better workaround be to include each of the OpenGL libraries (I'm not sure how they get selected) in the Steam FHS library path? Or will the usual locations not be in the search path either

I messed around with trying to get vrcomposistor-launcher to work with libcap. I am not sure if it could be related to the chroot being restricted or something related but I am not able to get it working either.

But I did find an alternative workaround which does not involve patching the vrclient libs

mv $HOME/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher $HOME/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher.backup
ln -s $HOME/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor $HOME/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher

This problem currently exists on my system. I tried the workaround suggested by the previous person involving creating a symbolic link, and it didn't have any effect. I haven't been able to find any system misconfiguration; steamVR Home works perfectly for every feature I have tried, but none of the handful of other games I've tried has successfully launched to the HMD. For example, BeatSaber in steam linux runtime mode fails to launch at all, and in proton mode it launches to the title screen, but displays it on the monitor rather than the HMD, it doesn't accept any input from the controllers, and needs to be force-killed.

Update. Changing the steamvr beta branch from linux_temp to no betas, deleting the steamvr.vrsettings file, reinstalling steamvr, then applying the workaround proposed by m4tsa fixed this problem on my system.

The superuser permissions are only needed to give the vr launcher executable thingy the capability to set a nice below 0 for better performance. This is optional of course and has nothing to do with the actual issue.

A few things you might want to do:

  1. Restart Steam/SteamVR, Reboot and re-plug. Yes, I know it's obvious but you wouldn't believe how often this has fixed my VR setup. I had the same error seen in OP's second screenshot yesterday and fixed it by restarting Steam and SteamVR.
  2. Make sure it actually works on Windows, SteamOS and/or Ubuntu; this might not be a NixOS problem.
  3. Try different ports for HDMI and USB
  4. Try a different DE/windowManager

I'm on unstable with i3 and works just fine on my Vive* after a bit of twiddling but getting VR to work properly is a bit of a process anyways.

* Well, about as fine as it can work on Linux currently. No power management or motion smoothing and bad stuttering on Nvidia :(

We should totally fix that superuser popup though, it's pretty annoying.

The superuser permissions are only needed to give the vr launcher executable thingy the capability to set a nice below 0 for better performance. This is optional of course and has nothing to do with the actual issue.

It is also required to enable async reprojection last time I checked, which is very important feature for having a stable framerate submitted to the HMD.

In my experience, giving it the cap_sys_nice that it asks for just breaks everything.

it seems like it works oob here, i don't know if async reprojection works though (how can i test?). the superuser popup is annoying to dismiss every time but i didn't have to fix any paths or anything

The superuser popup is supposed to set cap_sys_nice on vrcompositor-launcher, that's all it does.

If you don't allow that, SteamVR works but if you do it manually, the executable apparently takes a different code path and can't find libraries it depends on anymore.

Perhaps we should get in touch with Valve at this point, I'm pretty sure it's their application doing something weird now; not us.

I'll get a FHS compliant distro and check where SteamVR expects to find the libraries with the cap, maybe that can give us a hint.

This issue has gotten a bit bloated and most of the discussion has nothing to do with OP's problem, so I've created two new issues (see links above). One for the popup issue and one for the vrcompositor-launcher issue.

In the latter I have also made progress investigating why it works on other distros but not NixOS.

Is anyone still able to reproduce this bug?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tomberek picture tomberek  路  3Comments

teto picture teto  路  3Comments

copumpkin picture copumpkin  路  3Comments

ob7 picture ob7  路  3Comments

copumpkin picture copumpkin  路  3Comments