Possible directory/filesystem issue with VR games and SteamVR input

[Patola]

Your system information

• Steam Runtime Version: Steam Linux Runtime 3.0 (sniper) that comes with Proton 9.0-1
• Distribution (e.g. Ubuntu 18.04): Archlinux
• Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: Steam Runtime System Information
• If it helps, also: SteamVR report and System Information
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: [None / Steam Linux Runtime / Proton 5.13+ / older Proton] Proton 9.0-1 but the same happens with Proton 8.0-6 and GE-Proton9-1. Haven't tested other proton versions. Affects multiple games.
• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt? 0.20240415.0 and scripts 0.20240415.0
• What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt? 0.20240423.85482, pressure-vessel 0.20240422.0, scripts 0.20240422.0, soldier 0.20240423.85482
• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt? 0.20240423.85483, pressure-vessel 0.20240422.0, scripts 0.20240422.0, sniper 0.20240423.85483

Please describe your issue in as much detail as possible:

When running VR games on Steam via SteamVR, if the game is not under /home the VR input bindings are not correctly loaded. If I bring up the controller configuration for the game, "default" bindings is unselected and can't be selected. In the game, hand motion is recognized but button presses and trigger clicks aren't.

This issue doesn't trigger for all games that are not under /home, I can't find a reliable pattern. It triggers for most of my games, though.

This bug report comes from SteamVR-for-Linux#666 where the suspicion is that it comes from something from pressure vessel.
Tried changing steam linux runtime 1.0, 2.0 and 3.0 to the beta (one at a time), didn't change anything.

Did the following comparison:

• started steam with STEAM_LINUX_RUNTIME_LOG=1 2>&1 /tmp/steam-linux-runtime-1.log
• started steamVR, launch the game VTOL VR (667970) with PROTON_LOG=1. This game at this time was in the filesystem /jogos2 (/jogos2/SteamLibrary/steamapps/common/VTOL VR). The bug was triggered: I called the input configuration and it wouldn't let me change to default bindings (note that I never configured any custom bindings for this game and the others). In fact, it can't perform any function of the interface: it can't find other bindings and the button to create a new one doesn't work.
• left VTOL VR forcefully (since I can't access the menus to leave), left SteamVR.
• moved the game via steam ("move install folder") from filesystem /jogos2 to /home
• started steamVR, started VTOL VR. Everything works as expected. I go to the input configuration and default bindings is selected.
• I leave the game forcefully so that the log is the same for this part.
• I leave steamVR and exit steam.

Steps for reproducing this issue:

1. Run a SteamVR game that are not installed under the /home filesystem (e.g. installed in /games or something and this is a separate filesystem)
2. Try to click on something. It might not work (this bug doesn't trigger for all games), specifically the triggers and buttons.
3. Bring up the steam input configuration. See if the bindings can be set to default bindings. If they can't, this bug is triggered.

Games where this bug is confirmed to be trigger: No Man's Sky, VTOL VR. I can get a bigger list and I can try even native VR games if needed.

[Patola]

steam-linux-runtime-1.log.gz
-- the log from running steam with STEAM_LINUX_RUNTIME_LOG=1

[smcv]

-- the log from running steam with STEAM_LINUX_RUNTIME_LOG=1

It is not Steam's output that I would need to see: what I would need to see is the detailed log produced by the Steam Linux Runtime framework.

Depending where the bug is, I would expect to need to see either the log from starting SteamVR, or the log from starting the game. It is safest if you collect both.

Please use STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1, because I don't think _LOG collects all of the information I need (_LOG enables logging of messages at "info" level or higher, but _VERBOSE adds "debug" level).

The 100M log you collected seems to be because something (SteamVR? the game? OVR_AdvancedSettings? Steam itself?) is logging Error getting IVRInput Digital Action Data for handle very frequently. That is output from some other component that is not the container runtime framework, so adding STEAM_LINUX_RUNTIME_VERBOSE=1 shouldn't make this situation any worse.

started steamVR

With STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1, you should get a log with a filename like '/home/patola/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/var/slr-app250820-*.log. Please collect that, and attach it or send it as a Gist.

launch the game VTOL VR (667970)

This should leave a log in /home/patola/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/var/slr-app667970-*.log. Please collect this, too.

Because there are two components running in Steam Linux Runtime containers, there might be some "interesting" interactions between the two.

I can get a bigger list and I can try even native VR games if needed

If you can reproduce an equivalent issue with a native Linux title (no Proton), then that would help a lot to simplify the situation by eliminating Proton as a potential factor.

If the situation was equivalent, then your steps to reproduce would have to go something like this:

• have SteamVR installed in /home/patola/.local/share/Steam/steamapps/common/SteamVR
• install the native Linux game in a location like /jogos2/steamapps/common/WhateverGame
• run the native Linux game, it reproduces the issue
• quit
• workaround: tell Steam to move the native Linux game from /jogos2 to a Steam library situated in your home directory, so that it ends up stored somewhere like /home/patola/.local/share/Steam/steamapps/common/WhateverGame
• run the native Linux game, it does not have the issue any more

[smcv]

If you reproduce this with a different (native Linux) game, depending on exactly how that game is run, its logs might end up in a different place.

If the game runs in the legacy LD_LIBRARY_PATH runtime (this is the default for most native Linux games on desktop) then it will not leave a Steam Linux Runtime (pressure-vessel) log at all. This is normal. If you can reproduce the issue in this configuration, then probably the only log that is needed is the one from SteamVR, slr-appapp250820-*.log.

If you have configured the game to run in the "Steam Linux Runtime 1.0 (scout)" compatibility tool, it will leave a log in steamapps/common/SteamLinuxRuntime_soldier/var/slr-app${APP_ID}-*.log, where ${APP_ID} is the Steam app ID, for example 976930 for Groove Gunner. (Note: yes, I really did intend to say soldier here.)

If the game requires "Steam Linux Runtime 3.0 (sniper)", it will leave its log in steamapps/common/SteamLinuxRuntime_sniper/var/slr-app${APP_ID}-*.log.

Proton 8.0 or newer requires sniper, so if the game runs under one of these Proton versions, it will leave its log in steamapps/common/SteamLinuxRuntime_sniper/var/slr-app${APP_ID}-*.log.

Proton 5.13 to 7.0 inclusive required soldier, so if the game runs under one of these Proton versions, it will leave its log in steamapps/common/SteamLinuxRuntime_soldier/var/slr-app${APP_ID}-*.log. (But hopefully you are no longer using any of these versions!)

[Patola]

Thank you for the very detailed responses. I am under a very stressful week studying for a certification, I will respond to this message (and the other ones in the other bug report) after the weekend.

[farmboy0]

This might be the same error I was trying to fix here: ValveSoftware/Proton#6109
Basically action manifests containings windows paths

[Patola]

This might be the same error I was trying to fix here: ValveSoftware/Proton#6109 Basically action manifests containings windows paths

However as I said in my comment in the other bug report, the problem also occurs in at least one Linux native VR game, Groove Gunner. That game is unlikely to use windows paths.

[smcv]

Basically action manifests containings windows paths

If this affects Linux-native VR games too, then as @Patola said, Windows paths are probably not the problem.

However, this could point to a potential source of problems. If some component (SteamVR? the game? both? something else?) wants to load an "action manifest" that refers to other files by their absolute path, and that component is running in a Steam Linux Runtime container, then that's not going to work unless the SLR container has been given access to both the action manifest itself, and any other files that it points to.

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/shared-paths.md?ref_type=heads describes which files are/are not visible to the SLR container.

@farmboy0, if you understand the filesystem layout of this stuff, perhaps you would be able to answer the questions I asked in ValveSoftware/SteamVR-for-Linux#666 (comment)?