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

[kreiger]

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:

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

[kreiger]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

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

[smcv]

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]

Can confirm working perfectly with new beta

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

[kreiger]

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!

[smcv]

Thanks for confirming. Let's leave the issue open until the beta that resolves it has propagated to stable, and then we can close it after that.

[labatts]

When launching the soldier version of steam, I am getting the following error: An error occurred while launching this game: Invalid game configuration. (Again, this is when launching steam runtime 2.0 soldier, not a game. I guess it is referring to steam as a game.)

At any rate, Slay the Spire does NOT launch under soldier, but it DOES under the (regular?) steam runtime with the t -compat-force-slr off argument mentioned above (although it is very unstable and crashes very quickly). I tested a different game under the soldier, and it launches fine.

[smcv]

When launching the soldier version of steam, I am getting the following error: An error occurred while launching this game: Invalid game configuration.

There is a Steam Client bug where it incorrectly creates desktop shortcuts for compatibility tools, but when you launch those shortcuts, Steam opens instead and you get the "Invalid game configuration" error message. It's extra-confusing because the default icon for those shortcuts is the same as the icon for Steam itself. That's ValveSoftware/steam-for-linux#10306 but is out-of-scope for this particular issue report.

I would suggest deleting the "Steam Linux Runtime 2.0 (soldier)" desktop shortcut, to avoid mixing it up with Steam itself. The correct shortcut to launch Steam is normally just labelled Steam. If you are running Arch Linux or an Arch derivative, it might be Steam (Runtime) as a result of Arch's modifications.

There's no such thing as a soldier version of Steam - there is just Steam, and you're being misled by the incorrectly-created desktop shortcut.

(Again, this is when launching steam runtime 2.0 soldier, not a game. I guess it is referring to steam as a game.)

Not quite - it's trying to launch the Steam Linux Runtime 2.0 (soldier) compatibility tool as though it was a game. (But because it's a compatibility tool and not a game, that doesn't/can't work.)

It's "the same shape" as if you had let Steam create a desktop shortcut for Slay the Spire, which is actually implemented as: launch Steam, and then tell Steam to launch Slay the Spire.

Slay the Spire does NOT launch

That is probably this issue.

To resolve it, you could look for Steam Linux Runtime 2.0 (soldier) in your Steam library, go into its Properties → Betas, and set Beta Participation to client_beta. The beta version of SLR 2.0 provides an xrandr executable, fixing this.

If opting into that beta does not resolve this for you, then you must be seeing something different, in which case please open a separate issue with details of your system so that it can be investigated.

[smcv]

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.

The change that fixed this issue was included in the default branch of SLR 2.0 yesterday, so switching to a beta is no longer necessary.

If you stay on the beta, you'll get the latest improvements and bugfixes sooner. If a new beta causes some other regression for you, please report it to https://github.com/ValveSoftware/steam-runtime/issues, and then you should be able to work around it by switching back to the default, non-beta branch.

For a version that fixes this issue, SteamLinuxRuntime_soldier/VERSIONS.txt will say depot 0.20241111.107902 or newer.

[smcv]

@kisak-valve or @kreiger: I think we can close this issue now.