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

[smcv]

There is a new experimental feature in yesterday's beta of Steam Linux Runtime 2.0 (soldier), versioned 0.20241111.107902, which should make it easier to document a workaround for games like this one.

As an alternative to moving the outdated SDL2 out of the way, in the new beta you can set an affected game's Launch Options to:

STEAM_COMPAT_RUNTIME_SDL2=1 %command%

which will instruct the container runtime to override the version of SDL2 that is used. (Internally, this uses the SDL_DYNAMIC_API feature, which would otherwise be hard to document in a cross-distro way.)

As with any similar workaround or tweak, if you report bugs in a game where this workaround is active, please mention that the workaround is there so that developers can take it into account, and be prepared to re-test without it.

Note that even though the compatibility tool indicated in the UI is Steam Linux Runtime 1.0 (scout), the change actually happened in Steam Linux Runtime 2.0 (soldier) because of the way the compatibility tools are implemented, so it is Steam Linux Runtime 2.0 (soldier) where you would need to opt-in to the beta branch to get this new feature.

To opt-in to a compatibility tool beta, follow instructions similar to https://help.steampowered.com/en/faqs/view/5A86-0DF4-C59E-8C4A, but instead of locating Counter-Strike 2 and changing its Properties, you would do the same for SLR 2.0.

[smcv]

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

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

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

Yeah, thanks for mentioning it, but I'm going to say this sub-thread is out-of-scope.

If the game isn't working either way, then I don't think there is anything that we can do about this from the Steam Runtime side: we're taking your graphics drivers from the host system, so the best we can hope for is "graphics drivers work just as well as they did on the host system". We can't achieve miracles!

If you reach a situation where there is a configuration without using the SLR container that works, and a second configuration that uses the SLR container and doesn't work, then I think that is the time to look at opening a separate issue for it.

behaviour differences with Beta client vs Stable client

My first guess would be that these could be triggered by updates in one of the non-open-source parts of Steam, like perhaps the gameoverlayrenderer.so that is responsible for Steam Input, Steam Overlay and parts of Remote Play. Those are out-of-scope for the Steam Runtime. The reason I mention gameoverlayrenderer.so specifically is that it's code that gets injected into the game process, and it relates to GL/Vulkan rendering, so it seems plausible that it might be involved in a Mesa-related regression.

You could test this theory by setting Launch Options to env -u LD_PRELOAD %command% (which will break various Steam features for this particular game, but if it works, perhaps that's better than nothing).

that game has a drirc conf entry as well

We do try to symlink your drirc and drirc.d into the right place so that games inside the container will see them. STEAM_LINUX_RUNTIME_LOG=1 doesn't give detailed enough information to show you this happening, but if you set STEAM_LINUX_RUNTIME_VERBOSE=1 as well, you should see some references to it.

I believe Mesa also has an environment variable that you can set to make it log more information about its use of drirc, which might help you to find out whether that's actually being taken into account.

If you can find evidence that your drirc is not being taken into account, please open a separate issue with details - that's certainly something that we would want to fix.