Slay The Spire missing /usr/bin/xrandr after Steam Runtime update, fails to start

kreiger commented 6 days ago

Your system information

Steam Runtime Version: Soldier
Distribution (e.g. Ubuntu 18.04): Debian trixie/sid
Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: https://gist.github.com/kreiger/7e83dad71fc5ee0c0d1ba991f29c69d0
Have you checked for system updates?: [Yes/No] Yes
What compatibility tool are you using?: [None / Steam Linux Runtime / Proton 5.13+ / older Proton] None

What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt?

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?

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?

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:

A couple of days ago, i think just after midnight on november 6th, i tried to start Slay The Spire.

It didn't work, even though i had played it earlier on (i think) november 5th. I checked, and there had just been a Steam Runtime update downloaded.

Slay The Spire runs fine if i run it outside Steam.

After some debugging i find in the Slay The Spire logs:

Exception in thread "LWJGL Application" java.lang.ExceptionInInitializerError
        at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setVSync(LwjglGraphics.java:558)
        at com.badlogic.gdx.backends.lwjgl.LwjglApplication$1.run(LwjglApplication.java:124)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
        at org.lwjgl.opengl.LinuxDisplay.getAvailableDisplayModes(LinuxDisplay.java:954)
        at org.lwjgl.opengl.LinuxDisplay.init(LinuxDisplay.java:738)
        at org.lwjgl.opengl.Display.<clinit>(Display.java:138)
        ... 2 more

After some Googling: https://www.google.com/search?q=slay+the+spire+java.lang.ArrayIndexOutOfBoundsException%3A+0+at+org.lwjgl.opengl.LinuxDisplay.getAvailableDisplayModes

Apparently Slay The Spire depends on xrandr.

After some fiddling with SlayTheSpireTroubleshoot.sh i figure out that Slay The Spire is trying to run inside runtime "Soldier", which is missing /usr/bin/xrandr.

Steps for reproducing this issue:

Run Slay The Spire on Linux with latest runtime which doesn't have /usr/bin/xrandr

kreiger commented 6 days ago

I just found out about -compat-force-slr off from the november 5th patch notes.

I can confirm that starting Steam with -compat-force-slr off works around the issue, and Slay The Spire runs again.

michael-downey commented 6 days ago

I can confirm the problem and that the workaround using the -compat-force-slr off allows it to work. Also note it is the steam command line arguments not the game's arguments.

smcv commented 5 days ago

The container runtime doesn't include the majority of command-line tools, because well-behaved games and applications should usually use libraries. It looks as though LWJGL 3 correctly uses library code to get the display modes.

Unfortunately, Slay the Spire uses the legacy LWJGL 2 branch, which runs xrandr -q and screen-scrapes the output. (This has been known to be a problem since at least 2016)

xrandr is part of the x11-xserver-utils package, which is quite small itself; but it pulls in a C preprocessor (?!) which would add 33M to the runtime. So I think we're going to need to do some repackaging to install just xrandr but not the rest.

@TTimo, I'm inclined to add this for soldier but not sniper, as a way to draw a line between legacy and legacy-free environments - and if a game developer using Java wants to switch into sniper, they'll have to upgrade to LWJGL 3. Does that seem reasonable?

smcv commented 5 days ago

This has also been a problem with Slay the Spire even before the container runtime, because LWJGL is assuming that the host system will have an xrandr executable, but not all do.

TTimo commented 5 days ago

@TTimo, I'm inclined to add this for soldier but not sniper, as a way to draw a line between legacy and legacy-free environments - and if a game developer using Java wants to switch into sniper, they'll have to upgrade to LWJGL 3. Does that seem reasonable?

sounds good

kreiger commented 5 days ago

It's good that you're adding xrandr to the Steam Linux Runtime, but is there going to be an option in the future to run select games without the SLR?

smcv commented 5 days ago

Is there going to be an option in the future to run select games without the Steam Linux Runtime?

I don't know (not my decision), but if there is, it's always going to be "unstable": for instance Slay the Spire already doesn't work if the host system doesn't coincidentally provide its own xrandr. The way to have games that still work in 2034 will be if we can either improve the runtime, or fix the game, so that it runs successfully in the container.

michael-downey commented 5 days ago

I'm not quite sure what the purposal is for this fix. Before the latest update of scout everything was running fine for Slay The Spire. After update it stopped working. I have installed xrandr on my system but I am running a 64 bit system, I don't run 32 bit. I would expect that game developers would code towards a known system, so if scout is the 32bit original base system then that shouldn't change as I doubt developers would go back and update very old games.

smcv commented 5 days ago

Before the latest update of scout everything was running fine for Slay The Spire. After update it stopped working.

This is because the game is now running in a stricter and more future-proof environment, which is less likely to regress when your host system changes. The game not working in the new environment is unfortunate collateral damage from this, which we aim to address as soon as possible. The goal of this change is to ensure that this game (and others) will still be working in years to come.

This was triggered by an update of the Steam client, not an update of scout: both the old environment (the legacy LD_LIBRARY_PATH runtime) and the new environment (the container runtime) have essentially the same contents that they always did. The behaviour change is that the Steam client now does the equivalent of "Compatibility → Force the use of → Steam Linux Runtime 1.0 (scout)" for all older native Linux games by default.

I have installed xrandr on my system but I am running a 64 bit system, I don't run 32 bit.

The word size of the game is not relevant to this change. Steam requires a mixed 64/32-bit system, and the scout environement has always supported both 64- and 32-bit games.

I would expect that game developers would code towards a known system

We hoped that too - but unfortunately, they don't, and with the old environment it was incredibly easy for the game to accidentally rely on subtle details about the host system, like whether you have xrandr installed for some other reason.

We're intending to address this regression in Slay the Spire by adding a suitable version of xrandr to the container runtime, so that it will always be available, any time any user runs this game on any Linux distribution, forever.

penguinland commented 4 days ago

I, too, encountered this issue, and confirm that running steam -compat-force-slr off steam://rungameid/646570 from the command line works. I hope Valve fixes this problem quickly!

smcv commented 2 days ago

Addition of xrandr is queued up for a future beta.

Note that because of the way these components get released internally, this change will show up as an update to the Steam Linux Runtime 2.0 (soldier) tool. This is not the same thing as using betas of the Steam Client or the Steam Linux Runtime 1.0 (scout) tool.

You can opt-in to beta versions of SLR 2.0 by locating it in your Library, then following instructions similar to https://help.steampowered.com/en/faqs/view/5A86-0DF4-C59E-8C4A - but instead of changing the properties of Counter-Strike 2, you would change the properties of SLR 2.0 to use the client_beta branch.

smcv commented 1 day ago

This is believed to be fixed by Steam Linux Runtime 2.0 (soldier) beta build 0.20241111.107902, which was made available on the client_beta branch yesterday. The beta will be copied to the default branch when it has had some more testing.

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 the fix. Using the beta of Steam Linux Runtime 1.0 (scout) is not necessary, but is harmless (it doesn't change often, and is currently identical to the default branch).

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 Steam Linux Runtime 2.0 (soldier).

You can see the versions of the various compatibility tools that you currently have installed by reading steamapps/common/SteamLinuxRuntime*/VERSIONS.txt.

I'm inclined to add this for soldier but not sniper

I ended up adding xrandr to sniper too, since it's so small; that change happened in beta build 0.20241111.107899. This is not relevant for Slay the Spire, but might be useful in future for other LWJGL-2-based titles.

kkurczewski commented 23 hours ago

Just tested. Enabling client_beta on Steam Linux Runtime 2.0 (soldier) solved issue for me :+1:

smcv commented 23 hours ago

Just tested. Enabling client_beta on Steam Linux Runtime 2.0 (soldier) solved issue for me 👍

That sounds promising. @kreiger, please could you re-test?

zukigay commented 22 hours ago

Can confirm working perfectly with new beta

Edit: thanks for fixing this issue and future proofing it.

kreiger commented 15 hours ago

Just tested. Enabling client_beta on Steam Linux Runtime 2.0 (soldier) solved issue for me 👍

That sounds promising. @kreiger, please could you re-test?

I can confirm it works for me as well with Soldier client_beta.

Thank you for swift resolution!

ValveSoftware / steam-runtime