Relatedly, if a game was originally designed to run on scout, was already configured with "Steam Linux Runtime" (1070560), and is upgraded to a version that requires sniper (like Dota 2 did recently), at the moment it continues to be configured for "Steam Linux Runtime" even though that's no longer expected to work.
Ideally, it should automatically switch to its new default (sniper) when its previous configuration becomes unsuitable.
Relatedly relatedly, now that we have more than one SLR branch in active use, it would be great if their displayed names could be changed to something that indicates the sequence and has less emphasis on the codenames, perhaps something like:
Steam Linux Runtime -> Steam Linux Runtime 1.0 (scout/soldier)
Steam Linux Runtime - soldier -> Steam Linux Runtime 2.0 (soldier)
Steam Linux Runtime - sniper -> Steam Linux Runtime 3.0 (sniper)
I don't understand "install the Linux version and run it under the LD_LIBRARY_PATH-based scout runtime" should not be provided???
The only and right user way to tell dynamically the ELF loader where to look for a game "runtime" is LD_LIBRARY_PATH (and to a less extend LD_PRELOAD, and could be a private installation-time configured mechanism).
Game binaries could also (should?) be cleanely built with ELF DT_RUNPATH and could (should?) distribute properly their own runtime (since they could run in STEAM_RUNTIME=0 anyway).
Ofc, they would have to configure their own runtime: configure some non already defined (or override) env variables, for instance for libthai to find its data, or for some x11 data (usually if you use your own distributed shared lib, you would have to use the data with the right format/version and then distribute that data too).
I don't understand [why] "install the Linux version and run it under the LD_LIBRARY_PATH-based scout runtime" should not be provided???
Games that are compiled against sniper require newer libraries than the ones that the LD_LIBRARY_PATH-based scout runtime is able to provide. They get these from the Steam Linux Runtime 3 'sniper' container. There are technical limitations in the LD_LIBRARY_PATH approach that result in the LD_LIBRARY_PATH-based runtime being unable to upgrade some libraries beyond the oldest host operating system that Steam still supports (which is very old).
Game binaries ... could (should?) distribute properly their own runtime
This has been tried many times and it always breaks something, usually graphics drivers. One of Steam's biggest compatibility problems with native Linux games is when the game bundles a library that it should be picking up from elsewhere.
I will not discuss the design or purpose of the various Steam Runtime branches further here, because it is off-topic and will distract the developers who have the ability to fix the various problems we've reported. That's not beneficial to anyone.
I am sorry, but as far as know LD_LIBRARY_PATH is the only user level way, something is weird here as technically there is no other way.
Would tell me how you can acheive this?
(here or in the issue related to dota2 or a new one).
Relatedly relatedly, now that we have more than one SLR branch in active use, it would be great if their displayed names could be changed to something that indicates the sequence and has less emphasis on the codenames, perhaps something like:
Steam Linux Runtime -> Steam Linux Runtime 1.0 (scout/soldier) Steam Linux Runtime - soldier -> Steam Linux Runtime 2.0 (soldier) Steam Linux Runtime - sniper -> Steam Linux Runtime 3.0 (sniper)
This part has now mostly been implemented. Since last week, they are labelled "Steam Linux Runtime 1.0 (scout)", "Steam Linux Runtime 2.0 (soldier)" and "Steam Linux Runtime 3.0 (sniper)" when they appear in the Steam library.
However, the menu of possible compatibility tools activated by checking "Force the use of" still shows "Steam Linux Runtime". This option is app ID 1070560, the one we now call "Steam Linux Runtime 1.0 (scout)".
However, the menu of possible compatibility tools activated by checking "Force the use of" still shows "Steam Linux Runtime". This option is app ID 1070560, the one we now call "Steam Linux Runtime 1.0 (scout)".
This has also been relabelled to "Steam Linux Runtime 1.0 (scout)" now.
The original issue, that it is possible to select scout for games like CS2 and Dota 2 that are not designed to be run in scout, is still present.
Can sombody explain me what you are talking about ? Like in easy way, what button should I press to play dota 2 successfully on Steam deck?
@Xotabch1: This is a report of a specific issue in Steam's handling of compatibility tools, tracked here for the benefit of the Steam developers. It is not a general technical support forum, and the more noise we add to it, the longer it will take for the reported issue to be solved.
If you are affected by this specific issue, then the workaround for it would be:
Dota 2 → Manage (gear wheel icon) → Properties... → Compatibility → Make sure that "Force the use of ..." is not checked
If you are having trouble launching Dota 2 on Steam Deck, please open a separate issue or support request with full details, instead of replying to this one.
Edit: I think there is a difference of my issue being that I want the option whereas you want the default selection to cohere to the application better. If you can share any additional info however, I'd be grateful.
I had the issue of Aseprite switching over to the Windows version so I had to turn on forced compatibility and set it to the Steam Linux Runtime, but it still says it's v1.0 (Scout) with no other options for Soldier or Sniper. I might be automatically using Sniper for all I know, I don't know how to test for that. I believe my issue is the same one described here, yes?
Hello @mischiefaaron, your comment reads like it's related to https://github.com/ValveSoftware/steam-for-linux/issues/9875 instead of this issue report.
@mischiefaaron: As far as I can tell, what you are talking about is the opposite of this issue.
This bug report is about games like Dota 2 that specifically declare that they need to be run on Steam Linux Runtime 3.0 (sniper). The bug is that the Steam UI allows Steam Linux Runtime 1.0 (scout) to be selected for those games, but it shouldn't allow that: it isn't going to work, and we shouldn't offer users an option if we don't expect it to succeed.
It sounds as though you are asking about an app/game that, as far as Valve knows, is intended to be run in an environment that is compatible with Steam Runtime 1 (scout). As of 2023, Team Fortress 2 is one of many examples of a game like this. The answer is that it is intentional that you cannot choose to run these games in SLR 2.0 (soldier) or SLR 3.0 (sniper), and it's for a similar reason to this issue report: according to the best information we have available, we would not expect that choice to work correctly. Please see https://github.com/ValveSoftware/steam-for-linux/issues/7430 if you would like to read the technical details of why.
If the specific app/game you are referring to (Aseprite) is one that would benefit from being compiled and run in a Steam Linux Runtime 3.0 (sniper) environment like Dota 2 is, then please ask its developer to contact Valve and ask about getting it switched over. I believe the intention is that this will eventually become a "self-service" thing that any Steam game publisher can do, but for now, it requires intervention from a Valve developer. Battle for Wesnoth, Endless Sky and Retroarch are some examples of open-source games on Steam that have been through this process already.
This was mostly fixed in the current Steam client beta cycle (2024-04-xx). The beta branch of the various compatibility tools (versioned as 0.20240415 or newer) is currently required for the change to take effect.
This is fixed in the current Steam client beta cycle (2024-12-03), so we can probably close this next time the beta is shipped as stable.
This is fixed in the current Steam client beta cycle (2024-12-03), so we can probably close this next time the beta is shipped as stable.
Confirmed fixed in the 2024-12-04 general-availability Steam client (this change didn't make it into the release notes, but it's there).
Your system information
Please describe your issue in as much detail as possible:
A few native Linux games on Steam require the use of the Steam Linux Runtime 3.0 (sniper) container runtime, and are no longer supported or expected to run successfully in the traditional LD_LIBRARY_PATH-based Steam Runtime 1 'scout' runtime or the Steam Linux Runtime 1.0 (scout) that is based on it.
Known games that require sniper so far:
a non-default branch ofBattle for WesnothWhen configuring these games' properties, I should not be able to choose a compatibility tool that is known to be incompatible with the game. The valid/supportable choices are:
while these are not expected to work, and should not be offered for these games:
Steam Linux Runtime 1.0 (scout) (1070560) should only be offered for older games that were designed to run in the 'scout' environment.
Steps for reproducing this issue:
Expected result
The list contains various Proton versions (7.0, 8.0, etc.), and optionally "Steam Linux Runtime 3.0 (sniper)" (internally app ID 1628350).
The list should not contain "Steam Linux Runtime" or "Steam Linux Runtime 1.0 (scout)" (both are names for app ID 1070560), or "Steam Linux Runtime 2.0 (soldier)" (1391110).
Actual result
The list correctly contains various Proton versions, which is OK.
The list correctly does not contain "Steam Linux Runtime 2.0 (soldier)" (1391110), for the reasons described in #7430.
The list does contain "Steam Linux Runtime" (internally app ID 1070560). If I select it, the game is launched in an environment containing libraries older than the one the game was designed for, and it is likely to crash or run incorrectly.