search

ValveSoftware / steam-runtime

A runtime environment for Steam applications
Other
1.21k stars 86 forks source link

Possible directory/filesystem issue with VR games and SteamVR input #675

Open Patola opened 5 months ago

Patola commented 5 months ago

Your system information

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:

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 commented 5 months ago

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

smcv commented 5 months ago

-- 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:

smcv commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

This might be the same error I was trying to fix here: https://github.com/ValveSoftware/Proton/pull/6109 Basically action manifests containings windows paths

Patola commented 5 months ago

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 commented 5 months ago

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 https://github.com/ValveSoftware/SteamVR-for-Linux/issues/666#issuecomment-2158378265?