[BUG] SteamVR settings, in-game menu, and Home panels don't work.
Hello @literally-anything, I think I've seen this on my test box as well. If you completely close Steam, then run steam from a terminal and tell Steam to start SteamVR, is there a line in the terminal spew saying that libSDL could not be found?
I cannot seem to find anything in that log relating to SDL other than:
Loaded SDL version 3.0.0-1117-g727c7d4e2
Okay, thanks for checking. That's the Steam client itself, and not SteamVR.
I'm seeing the same issue, but also SteamVR home doesn't start (that is, SteamVR starts, just not the home application). Both in steam's combined terminal output, and when attempting to run steamtours manually, there's an invalid free and then tcmalloc abort()s:
src/tcmalloc.cc:390] Attempt to free invalid pointer: 0x5595f6477570
/home/implr/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_environments/game/steamtours.sh: line 94: 41439 Aborted ${STEAM_RUNTIME_PREFIX} ${GAME_DEBUGGER} "${GAMEROOT}"/${GAMEEXE} "$@"
I normally run without the steam runtime (and it used to work fine), but I've tested both with and without, the crash is identical.
I have the same issue on Arch.
https://gist.github.com/cornytrace/45aaf0e98a3255797e67edf4495a5a14
Except for the settings menu and in-hmd overlays, everything else works fine.
If I revert to the linux_v1.14 branch, the settings and overlays start working again, unfortunately this makes H3VR crash on launch.
Hello @cornytrace, please open a new issue report focusing on ./vrwebhelper: symbol lookup error: /usr/lib/libharfbuzz.so.0: undefined symbol: FT_Get_Transform in your log.
Hello @implr, can you check if mesa on your system is built against llvm 16? If it is, I suspect you're seeing a similar issue to https://github.com/ValveSoftware/Dota-2/issues/2285.
It is. I'll try rebuilding it with 15 later and see if that fixes it.
Removing llvm 16 completely and rebuilding mesa did fix steamtours (works normally), but did not fix the steamvr settings window (still no response either in the desktop ui or to the controller button). The invalid free is gone, I don't see anything else suspicious in stderr.
Beat Saber runs, HLA crashes because of #332, but that's probably unrelated.
While trying to fix HLA I came across #538 and decided to try launching steam with:
~/.local/share/Steam/steamapps/common/SteamVR/bin/vrenv.sh steam
As I understand this will run everything under the VR environment/runtime. This did break a lot of things (like random buttons in the main Steam UI not working due to KDE's libKF5* libs not being able to load) but.. fixed everything VR completely. Dialogs in SteamVR work, HLA runs.
Same here on Fedora 38 (Gnome/Wayland)
Same on Distrobox Arch container for ALVR (Fedora silverblue 38 Gnome/Wayland Host, happened on 37 too), AMD.
Actually i realised that it's not exactly the same for me, i just can't launch games via steamvr overlay. Otherwise opening steamvr settings, in-game menu, etc works. I also did apply my patcher that fixes binding reload spam, which fixes most issues related to long waiting for settings to show up
@kisak-valve I did a full reinstall of arch and the problem went away, the settings menu now also works.
Arch Linux, I seem to have the same bug, except when I went to follow @kisak-valve's thing about opening Steam in a terminal then SteamVR to see about a libSDL issue. Suddenly menus are interactable, although Steam desktop is claiming Error 303 but everything is working just fine.
For me, this was a problem with vrwebhelper not being able to find some of its libraries. Running it manually against the default heavy runtime yielded this:
$ /home/user/.steam/debian-installation/steamapps/common/SteamVR/bin/vrwebhelper/linux64/steam-runtime-heavy.sh --unpack-dir=/home/user/.steam/debian-installation/steamapps/common/SteamVR/bin/vrwebhelper/linux64 --runtime=steam-runtime-heavy -- ./vrwebhelper
Steam runtime environment up-to-date!
./vrwebhelper: error while loading shared libraries: libopenvr_api.so: cannot open shared object file: No such file or directory
Copying all of the .so files from vrwebhelper/linux64/ into vrwebhelper/linux64/steam-runtime-heavy/lib/x86_64-linux-gnu/ lets it launch correctly. I'm not sure if these will get overwritten when the heavy runtime updates, but it's a usable band-aid fix for now.
This worked for me as well, ld just doesn't know about those libs. I just added vrwebhelper/linux64/ to /etc/ld.so.conf.d/.
I'm seeing the same issue, but also SteamVR home doesn't start (that is, SteamVR starts, just not the home application). Both in steam's combined terminal output, and when attempting to run steamtours manually, there's an invalid free and then tcmalloc abort()s:
src/tcmalloc.cc:390] Attempt to free invalid pointer: 0x5595f6477570 /home/implr/.local/share/Steam/steamapps/common/SteamVR/tools/steamvr_environments/game/steamtours.sh: line 94: 41439 Aborted ${STEAM_RUNTIME_PREFIX} ${GAME_DEBUGGER} "${GAMEROOT}"/${GAMEEXE} "$@"I normally run without the steam runtime (and it used to work fine), but I've tested both with and without, the crash is identical.
This might be the same issue as https://github.com/ValveSoftware/SteamVR-for-Linux/issues/579.
Nothing extracted yet.
Describe the bug
In the beta version of SteamVR settings won't open, nor will the in-game menu. In SteamVR Home, the Big Picture and Desktop panes don't appear, they just freeze for a second and do nothing.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The settings should open when i click on it, but this seems to be an issue on windows as well sometimes.
When you click the menu button, the in-game menu that lets you quit the game, open a specific game, or view the desktop should open.
The Big Picture and Desktop panels should appear (In the non-beta version of SteamVR, this doesn't work either, the panes appear, but then SteamVR crashes).
System Information (please complete the following information):
Update: I've found 3 warnings/errors that could be related in the log
Note: Commenters who are also experiencing this issue are encouraged to include the "System Information" section in their replies.