Brütal Legend ( 225260 ), controller stopped working after SLR enablement on beta client ( more details in the issue, a bit complicated )

[Leopard1907]

Your system information

• Steam Runtime Version: 1.0 Scout
• Distribution (e.g. Ubuntu 18.04): Arch Linux (EndeavourOS)
• Link to your full system information: https://gist.github.com/Leopard1907/0c6f8b5ae04863b5d34178303fa7314b
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: SLR 1.0 Scout
• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt?:

Name    Version     Runtime Runtime_Version Comment
depot   0.20240806.0            # Overall version number
LD_LIBRARY_PATH -   scout   -   # see ~/.steam/root/ubuntu12_32/steam-runtime/version.txt
scripts 0.20240806.0            # from steam-runtime-tools

• What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?:

#Name   Version     Runtime Runtime_Version Comment
depot   0.20240917.101880           # Overall version number
pressure-vessel 0.20240916.0    scout       # pressure-vessel-bin.tar.gz
scripts 0.20240916.0            # from steam-runtime-tools
soldier 0.20240917.101880   soldier 0.20240917.101880   # soldier_platform_0.20240917.101880/

• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?:

#Name   Version     Runtime Runtime_Version Comment
depot   0.20240916.101795           # Overall version number
pressure-vessel 0.20240916.0    scout       # pressure-vessel-bin.tar.gz
scripts 0.20240916.0            # from steam-runtime-tools
sniper  0.20240916.101795   sniper  0.20240916.101795   # sniper_platform_0.20240916.101795/

Please describe your issue in as much detail as possible:

On Steam Beta client controller doesn't work with this app while on Steam stable client it does, with SLR 1.0 forced just like how Steam Beta client now does that by default.

Tested if this affects Proton titles but no, controller works with them. So possibly somehow that SLR enablement in beta client goes wrong.

STEAM_LINUX_RUNTIME_LOG=1 steam log retrieved:

slr-app225260-t20241018T222524.log

Steps for reproducing this issue:

1. A Dualshock 4 controller and Dualshock 4 config selected Steam Client wide in Controller settings
2. Brütal Legend native build
3. Seeing behaviour change between Stable client while SLR 1.0 forced to game vs Beta client that does it already

[smcv]

On Steam Beta client controller doesn't work with this app while on Steam stable client it does, with SLR 1.0 forced just like how Steam Beta client now does that by default.

I'm sorry, I don't think I understand this sentence. What's the truth table for the situations in which the gamepad does and doesn't work?

• Steam stable client, no specific configuration (not forcing a specific compatibility tool)
  • Gamepad works?
  • The game is probably running under the legacy LD_LIBRARY_PATH runtime?
• Steam stable client, forcing use of Steam Runtime 1.0 (scout)
  • Does the gamepad work?
  • Is the game running under the container runtime? (It should be)
• Steam beta client, no specific configuration (not forcing a specific compatibility tool)
  • Gamepad doesn't work?
  • Is the game running under the container runtime? (It should be)
• For completeness: Steam beta client, forcing use of Steam Runtime 1.0 (scout)
  • Gamepad doesn't work?
  • Is the game running under the container runtime? (It should be)

You can tell whether the game is running in the LD_LIBRARY_PATH runtime or the container runtime by looking at ~/.steam/steam/logs/console_log.txt.

The LD_LIBRARY_PATH runtime looks like this:

Game process added : AppID xxx ".../steam-launch-wrapper -- .../reaper SteamLaunch AppId=xxx -- THE ACTUAL GAME"

The container runtime looks like this:

Game process added : AppID xxx ".../steam-launch-wrapper -- .../reaper SteamLaunch AppId=xxx -- '.../steamapps/common/SteamLinuxRuntime_soldier'/_v2-entry-point --verb=waitforexitandrun -- '.../steamapps/common/SteamLinuxRuntime'/scout-on-soldier-entry-point-v2 -- THE ACTUAL GAME"

Or you can tell the difference by looking at the game's environment variables, perl -pe 's/\0/\n/g' < /proc/$pid/environ where $pid is the process ID of the game. Games in the container runtime will have PRESSURE_VESSEL_RUNTIME set (this is not an API guarantee, but in practice it's true). Games in the LD_LIBRARY_PATH runtime won't.

[smcv]

I notice from https://steamdb.info/depot/225274/ that this particular game contains a bundled copy of SDL, which is presumably quite old. It's probably older than the work I did in SDL to make gamepad discovery container-friendly.

After clarifying which situations work and which situations don't, please try moving steamapps/common/BrutalLegend/lib/libSDL2-2.0.so.0 out of the way (rename it to libSDL2-2.0.so.0.orig or something). Hopefully that will result in the game using the Steam Runtime's copy of SDL instead of its own, which might work better.

[Leopard1907]

Situation:

Beta client with that game in native form-> Controller doesn't work

Stable client with that game in native form but Steam Linux Runtime 1.0 forced via compat options-> Controller does work

I can try that renaming thing after i get home but tbh i'm not sure why would that change anything when situation is like described above.

Beta client itself forces 1.0 to every native game by default, no?

If yes; then why forcing 1.0 on Stable Client has working controller while beta client doesnt't have that.

Side note: That game is in dire need of SLR 1.0 because otherwise audio doesnt work.

[smcv]

Beta client with that game in native form-> Controller doesn't work

Stable client with that game in native form but Steam Linux Runtime 1.0 forced via compat options-> Controller does work

As you say, this is weird. I would have expected that these two scenarios should behave the same (and I think that's also your line of thinking): either the controller should work in both cases (which is what we all want to happen), or the controller should fail to work in both cases (which obviously would still be a bug, but it would be an understandable bug). It is strange that you observe different behaviour in these two cases.

Beta client itself forces 1.0 to every native game by default, no?

Sort of. It's best not to say "1.0" without further qualifiers, because every older native game is (at least in theory) designed to run under Steam Runtime 1.0 - but there are two different ways that can happen (the LD_LIBRARY_PATH-based runtime, and the container runtime), and the current beta cycle forces all of them to use the container runtime even if they didn't before.

But, if you were forcing use of Steam Linux Runtime 1.0 (scout) via game properties, then it's forcing use of exactly the same container runtime you were already using (and we haven't touched the actual container runtime since 2024-10-08), so I'm surprised that there's a difference.

[smcv]

I can try that renaming thing after i get home but tbh i'm not sure why would that change anything when situation is like described above.

It would give us a useful data point, and it might give you (and other players) a workaround.

I don't understand how the situation you've reported can have happened, but knowing whether this workaround works or not would help to bring us a little bit closer to understanding it.

[Leopard1907]

I notice from https://steamdb.info/depot/225274/ that this particular game contains a bundled copy of SDL, which is presumably quite old. It's probably older than the work I did in SDL to make gamepad discovery container-friendly.

After clarifying which situations work and which situations don't, please try moving steamapps/common/BrutalLegend/lib/libSDL2-2.0.so.0 out of the way (rename it to libSDL2-2.0.so.0.orig or something). Hopefully that will result in the game using the Steam Runtime's copy of SDL instead of its own, which might work better.

Doing this makes controller work in both:

• SLR 1.0 forced by user with beta client

• SLR 1.0 not forced by user, says selected by Valve testing with beta client

There is a behaviour change with this: Controller didn't vibrate before, now it does.

But issue of controller not working gets resolved by that renaming workaround.

[smcv]

Thanks. Based on that, it seems that as I suspected, the root cause here is that this particular game bundles an old copy of SDL2 that did not support enumerating game controllers in a way that works inside containers (older than 2.0.14, which fixed libsdl-org/SDL#3868). You can work around this by arranging for that copy of SDL2 to not be used.

What I don't yet understand is why, in the stable client, forcing use of Steam Linux Runtime 1.0 via compatibility options worked - that "shouldn't have worked" (without the workaround of moving the outdated SDL2 out of the way), for the same reason that it doesn't work in the beta.

[Leopard1907]

It is weird to me as well, but behaviour differences with Beta client vs Stable client with 1.0 runtime is not specific to this game either.

There is another weird behaviour that i didn't report ( because in its essence it is a Mesa bug ) but occurance of the Mesa bug on beta client vs stable client is different too.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/10018

On Stable client with 1.0 forced, it goes a bit past of initial company logos and crashes.

On beta client with 1.0 forced/not forced, it crashes at the first frame. Repro rate is 100 percent on my end.

Basically beta client makes the issue visible in the form like how it was originally reported, stable client with 1.0 makes the issue visible in a different way that doesnt classify as fully how it was originally reported.

Not sure if one should create an issue for that too as in the end it won't make the game work regardless.

Do note that game has a drirc conf entry as well, so maybe beta client somehow does neglect that entry.

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/00-mesa-defaults.conf?ref_type=heads#L959