Closed smcv closed 1 week ago
smcv
commented
1 week ago @TTimo, @kisak-valve ^ it's likely that this will indirectly trigger weird regressions for games that are meant to use SLR 3.0, so please bear that in mind when triaging: if a game is intended to run under SLR 3.0, it's worth checking that it is actually running under SLR 3.0 before investigating in more detail.
smcv
commented
1 week ago I cannot reproduce this for Counter-Strike 2, which still correctly runs under sniper. Perhaps this indicates that CS2 and Endless Sky/Retroarch were configured differently...
In my steam/logs/compat_log.txt, I can see that app ID 730 (CS2) has been mapped to SteamLinuxRuntime_sniper with priority 85, and SteamLinuxRuntime_sniper (again) with priority 100. Since my last Steam restart, lines relevant to 730 are:
[2024-11-11 14:43:54] Requesting mapping AppID 730 from appinfo to tool "SteamLinuxRuntime_sniper"
[2024-11-11 14:43:54] Recording non-user mapping for 730 at priority 85 to tool SteamLinuxRuntime_sniper
[2024-11-11 14:43:54] Mapping AppID 730 to tool "SteamLinuxRuntime_sniper" with priority 85
...
[2024-11-11 14:43:54] Recording non-user mapping for 730 at priority 100 to tool SteamLinuxRuntime_sniper
[2024-11-11 14:43:54] Unmapping AppID 730
[2024-11-11 14:43:54] Mapping AppID 730 to tool "SteamLinuxRuntime_sniper" with priority 100This looks correct. We have two configurations, at priority 85 (from CS2's own configuration?) and 100 (from the SteamPlay 2.0 manifests?), and we take the higher-priority one: and it doesn't actually matter which one we take, because they are both right. The situation for Dota 2 (570) looks very similar to CS2's.
Meanwhile Retroarch, App ID 1118310, has been mapped like this:
[2024-11-11 14:43:54] Requesting mapping AppID 1118310 from appinfo to tool "SteamLinuxRuntime_sniper"
[2024-11-11 14:43:54] Recording non-user mapping for 1118310 at priority 85 to tool SteamLinuxRuntime_sniper
[2024-11-11 14:43:54] Mapping AppID 1118310 to tool "SteamLinuxRuntime_sniper" with priority 85
...
[2024-11-11 14:43:54] Recording non-user mapping for 1118310 at priority 85 to tool native
[2024-11-11 14:43:54] Unmapping AppID 1118310
[2024-11-11 14:43:54] Mapping AppID 1118310 to tool "native" with priority 85where native is configured as an alias for SLR 1.0, I think. So we seem to have two contradictory configurations for Retroarch, with equal priority: the one "from appinfo" (from Retroarch's own configuration?) is right, the default (?) is wrong, but unfortunately their priority is equal, so it is unspecified which one wins. The situation for Endless Sky (404410) looks very similar to Retroarch's.
Team Fortress 2 has a slightly different configuration. Like Endless Sky and Retroach, it is not mentioned in the SteamPlay 2.0 manifests, but unlike Endless Sky and Retroarch, its per-app configuration has an explicit priority, 101, and this seems to result in it not being affected by Steam's new default:
[2024-11-11 14:43:54] Requesting mapping AppID 440 from appinfo to tool "SteamLinuxRuntime_sniper"
[2024-11-11 14:43:54] Recording non-user mapping for 440 at priority 101 to tool SteamLinuxRuntime_sniper
[2024-11-11 14:43:54] Mapping AppID 440 to tool "SteamLinuxRuntime_sniper" with priority 101I think the rule that says "native Linux games run under SLR 1.0" needs to be given a lower priority than 85, so that it won't "win" vs. games' own per-title configuration saying they should run under SLR 3.0.
smcv
commented
1 week ago We think we know why this is happening, a potential fix is queued.
smcv
commented
1 week ago On desktop, this seems to be fixed in beta 1731377496 (November 11).
There was a Steam Deck beta the same day with "Fixed native titles occasionally running in the wrong runtime" in its release notes - that sounds like this fix.
smcv
commented
1 week ago This regression was not necessarily completely deterministic: depending on the order in which the Steam client reads or re-reads various sources of configuration, either of the two information sources that had priority 85 could "win". If the per-app configuration wins, affected games correctly run under SLR 3.0. If the default to SLR 1.0 wins, they incorrectly run under SLR 1.0.
I think the rule that says "native Linux games run under SLR 1.0" needs to be given a lower priority than 85, so that it won't "win" vs. games' own per-title configuration saying they should run under SLR 3.0.
The change that was made in the November 11 betas to solve this appears to have been to lower the priority of "native Linux games run under SLR 1.0" to 75, so that games' own per-title configuration at priority 85 will correctly take precedence in a deterministic way.
The priorities are now: default to SLR 1.0 (75) < per-title configuration (85) < SteamPlay manifests (100) < user configuration (250); those hopefully make the right thing happen in all cases.
smcv
commented
1 week ago The change that was made in the November 11 betas to solve this appears to have been to lower the priority of "native Linux games run under SLR 1.0" to 75, so that games' own per-title configuration at priority 85 will correctly take precedence in a deterministic way.
I believe this fix was copied into the general-availability client on November 12, https://store.steampowered.com/news/app/593110/view/4480613067569233923
Your system information
Please describe your issue in as much detail as possible:
Some
(all?)titles that have been flagged by their developer/publisher to be run under the Steam Linux Runtime 3.0 (sniper) container runtime are actually getting run under the Steam Linux Runtime 1.0 (scout) container runtime.This happens to work OK for the first two games I tested, but is likely to cause crashes or weird regressions in some titles that were compiled in the SLR 3.0 SDK and genuinely do need the newer runtime: SLR 3.0 uses core libraries from Debian 11, but SLR 1.0 uses core libraries from Debian 10, which is 2 years older.
I suspect that this is related to the change that forces use of the SLR 1.0 (scout) container runtime for titles that previously used the legacy
LD_LIBRARY_PATH-based scout runtime. Perhaps that change is unintentionally forcing use of the SLR 1.0 container runtime for all native Linux titles, even if they were designed for SLR 3.0?Steps for reproducing this issue
~/.steam/steam/logs/console.logto see exactly what we ranExpected result
The game is running under Steam Linux Runtime 3.0 (sniper), with a command-line that in my case should look something like this:
(Key facts: it's using the
steamapps/common/SteamLinuxRuntime_sniperentry point script, and is not usingsteamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2)Actual result
The game is running under Steam Linux Runtime 1.0 (scout), with a command-line that looks something like this (lines broken for clarity, in the real log it is one very long line):
(Key facts: it's using the
steamapps/common/SteamLinuxRuntime_soldierentry point script - not sniper as intended - and it is usingsteamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2)Workaround
Run Steam as:
Logs
In these logs, I ran Steam with no special command-line options (as
steam), launched Endless Sky at 12:05, and saw that it ran in the incorrect environment.Then I completely exited from Steam, ran Steam as
steam -compat-force-slr off, re-launched Endless Sky at 12:10, and saw that it ran in the correct environment (the workaround was successful).steam-logs.tar.gz