Allow selection of Steam Linux Runtime in Game List

[xperia64]

Is your feature request related to a problem? Please describe.
Currently, Steam hides the Soldier (2.0) and Sniper (3.0) Steam Linux Runtime compatibility tools in the Compatibility tab of games and does not allow them to be selected manually; only Scout (1.0) can be chosen.

While the primary purpose of ProtonUp-Qt is managing versions of Proton, it already has the necessary infrastructure in place to configure arbitrary compatibility tools for games.

Describe the solution you'd like
I would like the Compatibility Tool dropdown menus to show the steamlinuxruntime variants, or at least have the option for them to appear.

Describe alternatives you've considered
Editing config/config.vdf manually via a text editor works, but is inconvenient.

Additional context
I am opening this as an issue rather than a PR as I'm not sure if you want to always show the Steam Linux Runtimes or have some checkbox somewhere.

Additionally, while get_steam_ctool_list in steamutil.py already has an optional argument to allow showing non-Proton compatibility tools, Steam Linux Runtimes are not currently enumerated as compatibility tools even if that is set to True.

The section of update_steamapp_info that handles Steam Linux Runtimes could be updated as follows to address this:

elif 'Steam Linux Runtime' in a.game_name:
    a.app_type = 'runtime'
    if steam_app.get('appid') in ctool_map:
        ct = ctool_map.get(steam_app.get('appid'))
        a.ctool_name = ct.get('name')
        a.ctool_from_oslist = ct.get('from_oslist')

[sonic2kk]

Steam Linux Runtime 1.0 is for Native Linux games only and is the only one that is actually a compatibility tool, 2.0 and 3.0 are for Proton games only and are used to launch Proton games in a container, they are not standalone compatibility tools but are meant to be used with compatibility tools. Steam does not show these because they cannot be used as standalone compatibility tools. Only 1.0 Scout can be used for games and this is for native games only. ProtonUp-Qt does not list them for similar reasons.

ProtonUp-Qt should already be showing the Steam Linux Runtime 1.0 on the Games List. I was just able to use it to select the Steam Linux Runtime for Half-Life:

It does now show 2.0 and 3.0 because, as mentioned, these cannot be used for games regularly.

The launch command for 2.0 and 3.0 are prepended to a Proton game's launch command. Proton flavours based on Proton 5.13 and above enforce the use of the Steam Linux Runtime, and in their files they have a text file called toolmanifest.vdf. This has a section called require_tool_appid which denotes the AppID of the Steam Linux Runtime required for that tool.

Steam uses this for two things:

1. To download the relevant tool (i.e. the relevant SLR if it is not downloaded) before a game launch, so if a tool requires SLR Sniper 3.0, it will make sure that is downloaded before a game is launched
2. To know how to find the relevant compatibility tool path to prepend to the game launch command

For example, GE-Proton8-25 uses SLR 3.0 Sniper (and Valve Proton 8, in fact, I think all Proton 8 variants use Sniper). Here is what the start command for a game using SLR 3.0 Sniper looks like:

/run/media/emma/500GB SSD/Games/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun -- /run/media/emma/500GB SSD/Games/steamapps/common/Proton 8.0/proton waitforexitandrun /run/media/emma/500GB SSD/Games/steamapps/common/CHAOS;CHILD/boot.bat

SLR 1.0 Scout is appended in a similar way, but they are used differently. Only Scout 1.0 can be used as a compatibility tool, the 2.0 and 3.0 containers are only for use as part of a launch command (i.e. to launch games inside the given pressure-vessel container). Their file structure and purpose are different, you can inspect this yourself with "Browse local files" from the Steam Client (you can search "Steam Linux Runtime" or the specific AppIDs in the Steam library search).

Even though 1.0 Scout does not have compatibilitytool.vdf, Steam knows to display 1.0 Scout and use it for native games only by way of some information in the binary appinfo.vdf, similar to how it manages its own internal Proton versions as well and can still display them even if they are not installed. Essentially the information in appinfo.vdf can act as a hardcoded list of compatibility tools, and ProtonUp-Qt gets the Valve compatibility tool information from appinfo.vdf. 2.0 and 3.0 are not here because they are not compatibility tools.

This does not appear for Proton games because the 1.0 Runtime is for native, 2.0 and 3.0 are the libraries Proton versions are built against.

---

SLR 1.0 can be used a compatibility tool because it wraps the native Linux game start command. But for Proton games, the Proton script is the wrapper around the game launch command. Therefore it doesn't make sense for SLR 2.0 and 3.0 to be compatibility tools anyway, which is why Valve did not create them as such. They have to be the top-level wrapper because they wrap the Proton start command. 2.0 and 3.0 can't dictate which Proton version to launch with, and they also cannot launch native games, so I hope that helps illustrate why they are made as compatibility tools, there would be no way for it to work. It couldn't wrap a Proton launch command.

If they were used to start a program, it would look like this (it cannot do this fwiw because Steam cannot use the tools this way):

# Will not work properly, will either fail, or try to use the system to launch the game instead of Proton
"/run/media/emma/500GB SSD/Games/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point" --verb=waitforexitandrun -- /path/to/game.exe 

# May work, but is not intended usage, and Steam does not allow this usage anyway
"/run/media/emma/500GB SSD/Games/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point" --verb=waitforexitandrun -- /path/to/nativegame

Instead, Steam is responsible for wrapping the Proton launch command in the require_tool_appid, it wraps that Proton launch command in the required AppIDs launch command. Since Proton knows how to wrap the game launch, Steam then takes that launch command and wraps it in the required SLR. This is why tools which wrap start commands (such as SteamTinkerLaunch) have to construct the SLR start command separately.

---

In short, Scout 1.0 is already supported, and 2.0 and 3.0 cannot be supported because they are not compatibility tools.

[xperia64]

My use case is the latter of the two, for a native Linux SLR program I built in the sniper toolbox.

It's unfortunate that there's no supported elegant way of telling steam to run a non-Steam shortcut in sniper.

Setting the full path to run-in-sniper works, but is rather clunky to have to set as the command for each program, and setting CompatToolMapping in config.vdf works and is fairly nice, but evidently isn't supported.

I guess I'll just keep on manually setting steamlinuxruntime_sniper for these shortcuts in my config.vdf until it breaks.

[sonic2kk]

It is indeed possible to run games in 2.0 and 3.0 but it is not intended usage, otherwise Steam would allow you to do it :-) They are not meant to be used as compatibility tools, even if they can work, they are meant for targetting Proton, and 1.0 is the one that Valve give updates to for native game improvements.

Even on SteamOS, Verified/Playable native games are only ever set to run in 1.0. I don't think ProtonUp-Qt should go against what Steam provides for official compatibility, Steam most certainly does not provide this option for a reason, and displaying these runtimes when they're not available from Steam is probably not a good idea.

[xperia64]

While I acknowledge that 2.0 is discouraged as a native Linux target, 3.0 is intended to be the successor for 1.0, and there are a handful of released titles already targeting it: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#native-linux-games-targeting-steam-runtime-3-sniper

I confirmed RetroArch actively uses Sniper, and Endless Sky is listed as Playable.

[sonic2kk]

When the Steam Client starts using Sniper instead of Scou, or displays both, then ProtonUp-Qt could probably pick it up. But while the Steam Client doesn't display it I'm not sure ProtonUp-Qt should either... That's just my opinion though.

Also, Endless Sky uses Proton on SteamOS, as listed on SteamDB. The recommended runtime is Proton 7.0. I have not seen any native games verified or playable as native using anything other than 1.0. It's pretty common for native titles to be Verified/Playable with Proton on SteamOS.

For RetroArch, I thought they bundled a runtime on their own (mist). Although it may specify somewhere In its files for Steam to use 3.0, that's a per-game configuration option and not really the same as enforcing a compatibility tool.

Perhaps Valve want developers to start targetting 3.0, but for now the only compatibility tool you are really supposed to force is 1.0. But in light of what you've shared, perhaps eventually 3.0 will be listed in the Steam Client.

Until then though I'm not sure ProtonUp-Qt should actually display it. Again that's just my opinion and my concern is allowing this when the Steam Client doesn't. There's likely a reason the client doesn't yet, and I'm concerned about going against that.

I would also be slightly concerned about currently displaying both, and not just because this is displaying an option that the Steam Client doesn't provide. But this is much more minor.

If we make a change to display both, but then the Steam Client makes a change to only display one (i.e. 3.0), then ProtonUp-Qt would need to make this change as well to be consistent. We would essentially end up playing catch-up more than we need to. If we wait for the Steam Client to start displaying 3.0 we can follow their lead.