ValveSoftware
scout_layered_slim breaks Kopanito (399820)
This is a follow up to this issue: https://github.com/ValveSoftware/steam-runtime/issues/410#issuecomment-849058118
Your system information
- Steam Runtime Version: steam-runtime_0.20210422.0
- Distribution (e.g. Ubuntu 18.04): Fedora 33
- Link to your full system information
- Have you checked for system updates?: [Yes]
- Are you using the Steam Linux Runtime compatibility tool?: [Yes]
Please describe your issue in as much detail as possible:
Game does not react to any gamepad input. It eventually freezes up on the title screen, at least once you try to open the BP overlay a few times too much. Does not happen with the default runtime.
Steps for reproducing this issue:
- Enable scout_layered_slim and restart Steam
- Enable Steam RT in properties and Launch Big Picture
- Launch game
- Try doing anything on the home menu screen with a gamepad, including opening the Big Picture overlay.
What exactly do you mean by "the default runtime"?
The four possible scenarios for running a native Linux game are:
- (1) don't enable "Steam Linux Runtime" compat tool (we call this "the
LD_LIBRARY_PATHruntime" because of how it works internally) - do enable the "Steam Linux Runtime", and either:
- (2) don't choose a beta in the Properties of the "Steam Linux Runtime"
- (3) choose
client_beta - (4) choose
scout_layered_slim
You've said that (4) doesn't work, and that something else does work. Is the working scenario (1) or (2)?
If (1) is the working scenario, it would be useful to try (2) and report whether the game has the same gamepad issues there. (Sorry, you'll have to re-download the full runtime.)
Similarly, if (2) is the working scenario, it would be useful to try (1).
From the file list on SteamDB, this looks like an Electron-based game, which might be significant. I would guess that Electron might have its own implementation of controller enumeration; if it does, then it won't benefit from the code we added in SDL to get more container-friendly controller enumeration.
Working scenarios are both (1) and (2)
Interesting. Thanks for reporting this - this is the first example we've encountered of scout_layered_slim being a regression.
See linked thread. Nothing has changed.
Please could you quote the version information even if nothing has changed, so we don't have to cross-reference between different issue reports to find out what your system is?
Even if you haven't upgraded your system, the Steam Runtime has probably been upgraded (0.20210422.0 is not the current version) which could affect what is going on.
It's also useful to see your SteamLinuxRuntime/VERSIONS.txt and SteamLinuxRuntime_soldier/VERSIONS.txt so that we can keep track of which container version you are using.
It would be useful to see a log from the broken scenario with scout_layered_slim (the one I labelled as (4) above), and another log from the closest equivalent that is working, which would be the default branch of "Steam Linux Runtime" (the one I labelled as (2) above).
If you can run Steam with environment STEAM_LINUX_RUNTIME_LOG=1, that would be the best: that'll show us the diagnostic output from the pressure-vessel tool that starts the container, and also any warnings or errors from the game itself.
With the default branch (2), the log can be found in SteamLinuxRuntime/var/slr-app399820-*.log. With scout_layered_slim (4), because the way the container starts up is different, the log we want to see is SteamLinuxRuntime_soldier/var/slr-app399820-*.log.
If you can't run Steam with STEAM_LINUX_RUNTIME_LOG=1 for some reason, like you said on #410, then that is a bug somewhere, which we need to fix. Please explain in more detail what is happening. Until we get this solved, there are some things you could try which would give us partial information: if you run steam from a terminal (gnome-terminal or xterm or similar), then at least we will be able to see any warnings or error messages from the game itself (they'll appear in the terminal instead of in a log file). Running it with PRESSURE_VESSEL_LOG_INFO=1 would give us some extra information from the pressure-vessel tool which could also be useful to diagnose what is happening.
If you can't run steam from a terminal either, then its output might be going to the systemd Journal?
@RyuzakiKK tried this and had different results:
- (1) LD_LIBRARY_PATH runtime: at first loading screen, game has 100% load on a single core, and then after a few seconds it crashes
- (2) default SteamLinuxRuntime branch: not tested
- (3) SteamLinuxRuntime
client_beta: same as (1) - (4) SteamLinuxRuntime
scout_layered_slim: same as (1)
and then after disabling "Steam Overlay while in-game":
- (1) LD_LIBRARY_PATH runtime: game works, without features that rely on the Steam Overlay (game controller mapping)
- (2) default SteamLinuxRuntime branch: not tested?
- (3) SteamLinuxRuntime
client_beta: same as (1) - (4) SteamLinuxRuntime
scout_layered_slim: same as (1)
which seems like an incompatibility between the Steam Overlay and the game's Electron/node.js runtime, but not a regression in scout_layered_slim. If your results are different, we'll need to see logs or other output as requested in my previous comment.
From your mention of gamepad input and the Big Picture overlay, it sounds as though the symptoms you are seeing are also related to the Steam Overlay.
In both cases the default SteamLinuxRuntime branch (2) gives the same result as (1).
