[halgari]

Summary

• Adds the most basic game detection support for Steam on Linux. Individual games will still need to be debugged and verified on Linux
• Add Linux Steam path discovery supporting multiple installation methods (native, Flatpak, Snap, Debian
  symlinks)
• Detect Proton usage and resolve configured Proton version for Steam games
• Automatically launch Linux Steam games through Steam (which handles Proton)
• Enable running Windows tools (.exe) through Proton using the game's existing prefix

Details

Linux Steam Discovery (src/util/linux/steamPaths.ts)

Steam on Linux can be installed in various locations depending on the distribution and installation method. This
adds detection for native installs (~/.local/share/Steam), Flatpak, Snap, and legacy paths.

Proton Detection (src/util/linux/proton.ts)

For games using Proton, we need to find the configured Proton version to run tools. Steam stores config names
(e.g., proton_experimental) in config.vdf, but actual folder names differ (e.g., Proton - Experimental).
Since Steam provides no mapping, we use filesystem scanning with fuzzy matching—no hardcoded version map that
would need maintenance.

Game Launching (src/util/StarterInfo.ts)

Linux Steam games now automatically use the Steam launcher, which handles Proton configuration. This avoids
Vortex needing to replicate Steam's Proton launch logic.

Tool Execution (src/util/Steam.ts)

Windows tools (.exe) associated with Steam games can now run through Proton using the game's existing Wine
prefix, allowing mod tools to work on Linux.

Known Issues

• Due to how games are launched Vortex can't detect the game's PID and so doesn't know when the game exits. In a future PR we can investigate how to do running game detection via scanning running processes or other methods
• Depending on how tools/games are launched by extensions some work may yet need to be done. For example the SkyrimSE extension launches Steam fine via proton, but does not yet detect SKSE or know where to write settings. I debugged this, we now run proton directly with settings from Steam meaning SKSE works fine

Test plan

• Verify Steam path detection on native Linux Steam install
• Verify Steam path detection on Flatpak Steam install
• Test launching a Proton game through Vortex
• Verify no regression on Windows (Linux code paths are gated by platform checks)

[IDCs]

Code looks good.

Can confirm there's no regression on Windows. @erri120 | @Sewer56, can you please test the implementation on Linux?

[erri120]

Are we sure we want to internalize the ability to launch proton directly? In the app we decided against internalizing and instead using protontricks to handle running commands because it sets up everything for us: https://github.com/Matoking/protontricks/blob/7ee7ee0a612064e3bb722de7b3ad7036d3bbfd3c/src/protontricks/util.py#L444

[Continous]

Are we sure we want to internalize the ability to launch proton directly? In the app we decided against internalizing and instead using protontricks to handle running commands because it sets up everything for us: https://github.com/Matoking/protontricks/blob/7ee7ee0a612064e3bb722de7b3ad7036d3bbfd3c/src/protontricks/util.py#L444

Protontricks is also more likely to closely follow Proton developments that might otherwise break an internalized feature.

[Sewer56]

Fine by me. Same comment as the two above; but not a big deal for now.
There haven't been any major breaking changes I can think of in a while, though, so for now this is fine.

Looking at this reminds me that last I tried, building a static protontricks was a PITA, nevermind the manual maintenance of version updates afterwards.

As far as things go longer term. Supporting other stores may require the likes of umu; but that's not set in stone. e.g. If we go the route of instead supporting Heroic again for GoG, they'd be doing that for us on their end. We just invoke via Heroic as usual, like with NMA.

[rednaxela600]

I built the linux-steam-finder branch on ultramarine linux. (fontconfig-devel needed to be installed manually). I successfully launched Fallout 4 through steam/proton (native steam package, not flatpak) from Vortex's play button. I have a 20 second video if it's acceptable to attach it here.

Vortex detected Fallout 4's game path just fine, however related paths are checking for things like Fallout4.ini and Fallout4Prefs.ini in "home/{username}/Documents/..." instead of the game's respective wine prefix. For reference, in my case fallout 4's prefix would be in "/home/xela/.steam/steam/steamapps/compatdata/377160/pfx/". I'm not sure if " Verify Steam path detection" is just referring to the game folder itself or if this is included, but I thought I'd mention it.

[halgari]

Are we sure we want to internalize the ability to launch proton directly? In the app we decided against internalizing and instead using protontricks to handle running commands because it sets up everything for us: https://github.com/Matoking/protontricks/blob/7ee7ee0a612064e3bb722de7b3ad7036d3bbfd3c/src/protontricks/util.py#L444

Whatever we do, I'd rather not have additional setup steps for users. Is protontricks installed by default on SteamOS? If not can't we just launch games using whatever method Steam uses?

I'd like to avoid having to mod the mod manager in order to have things work for users. Or perhaps we can have protontricks included in flatpack (maybe that's crazy talk) or installed as a prerequisite for the Vortex flatpack? Whatever we do, I really just want a download the app and it works out-of-the-box.

[erri120]

Is protontricks installed by default on SteamOS

No.

If not can't we just launch games using whatever method Steam uses?

The Steam browser protocol allows you to launch games through Steam but it doesn't allow you to run arbitrary commands.

I'd like to avoid having to mod the mod manager in order to have things work for users. Or perhaps we can have protontricks included in flatpack (maybe that's crazy talk) or installed as a prerequisite for the Vortex flatpack? Whatever we do, I really just want a download the app and it works out-of-the-box.

Flatpaks can't depend on another flatpak by design. App-to-app dependency chains are deliberately avoided because that'd break the sandbox. The common approaches to this are

1. to vendor protontricks, or
2. rely on a pre-installed version of protontricks

[insomnious]

I'm happy that we just internalize it and get this PR wrapped up. Seweryn is going to be working on Flatpak next week.

[SulfurNitride]

Hey, so for what it's worth a lot of the protontricks can be fully replaced with winetricks and just using the GitHub binary raw file. It's late so I pulled this directly from Claude as an example of the things that I do to ensure mo2 integration with steam.

rundown.md

I know its written in rust, but you should be able to get the idea if you want to even take a look at it in the first place. NaK I just thought I'd drop by with some ideas. A lot of the winedlloverrides can be written to a registry file and applied via proton itself removing the need for launch options.

If I had the chance to support or request a feature, my only request would be having an option to chose your own location for a prefix. Because I'd love to support the Linux port of vortex but it wouldn't really be possible if I can't get a dedicated prefix for it. (And yes spooky sloppy ai for my personal projects lol)

Edit: And for linux game detection, any reason why you couldn't just rewrite support for GameFinder to be incorperated into vortex?

[loathingKernel]

There are some glaring omissions in the implementation.

• It doesn't search for proton in the system-wide directory i.e. /usr/share/steam/compatibilitytools.d
• It doesn't handle standalone <compatibility_tool>.vdf files in any of the search locations. https://github.com/ValveSoftware/Proton/blob/proton_10.0/compatibilitytool.vdf.template
• It doesn't run proton in the expected Steam Linux Runtime environment. The required runtime appid is available in toolmanifest.vdf. If the attribute is missing, it means that no runtime should be used to run this tool. https://github.com/ValveSoftware/Proton/blob/proton_10.0/toolmanifest_runtime.vdf
• The proton detection is based on the name of the proton script, which is mutable. toolmanifest.vdf contains identifying information in compatmanager_layer_name attribute. This is minor though, as the script's name is unlikely to change.
• Running tools that need to access the game process's memory can be tricky, using the same prefix is not enough. Since proton and thus games run in a container, they use a different namespace, which will block any such tools from working. One way to handle it would be to use pv's debugging facilities.

More documentation:

• https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/steam-compat-tool-interface.md
• https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#inserting-debugging-commands-into-the-container

[SulfurNitride]

There are some glaring omissions in the implementation.

• It doesn't search for proton in the system-wide directory i.e. /usr/share/steam/compatibilitytools.d
• It doesn't handle standalone <compatibility_tool>.vdf files in any of the search locations. https://github.com/ValveSoftware/Proton/blob/proton_10.0/compatibilitytool.vdf.template
• It doesn't run proton in the expected Steam Linux Runtime environment. The required runtime appid is available in toolmanifest.vdf https://github.com/ValveSoftware/Proton/blob/proton_10.0/toolmanifest_runtime.vdf
• The proton detection is based on the name of the proton script, which is mutable. toolmanifest.vdf contains identifying information in compatmanager_layer_name attribute. This is minor though, as the script's name is unlikely to change.

More documentation: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/steam-compat-tool-interface.md

I was just giving some information as a lot of this can easily be modified/handled.

And as for the SLR I have found no issues not using for prefix creation, with users using flatpak or native steam. At least in my testing on NaK. Again I was just giving my thoughts and opinions, as the winetricks method is something Omni uses in Jackify as well.

[loathingKernel]

@SulfurNitride I believe you quoted my comment by mistake. I am referring to the general implementation of this PR, not to your suggestion.

As for not using the SLR, well, it is being used for a reason by Steam, no matter how many issues you encounter or not, you cannot be certain that it will work for everyone.

[killzoms]

Interesting tidbit about the basic implementation here, apparently having both Skyrim SE and Skyrim SE Creation Kit installed on Linux causes Vortex to prioritize the Creation Kit compatDataPath instead of the one that actually matches the appId

[6d657263757279]

Are we sure we want to internalize the ability to launch proton directly? In the app we decided against internalizing and instead using protontricks to handle running commands because it sets up everything for us: https://github.com/Matoking/protontricks/blob/7ee7ee0a612064e3bb722de7b3ad7036d3bbfd3c/src/protontricks/util.py#L444

Just some feedback: if there is a method of avoiding protontricks and making use of proton installations that come with Steam, it might be better for end-user experience, especially as more and more less-savvy users make the switch to Linux. The Linux experience should ideally be as seamless and user-friendly as its Windows counterpart. As more games become supported on Linux, adding extra layers on top the ones that already exist (extensions to enable Vortex support as an example), may add complexity and could affect modding cross-compatibility between Windows and Linux (for users that have a Win desktop and Steam Deck, for example).

[Sewer56]

@6d657263757279 Protontricks is just a wrapper around Steam's Proton installations.

To be more precise, it's a wrapper around winetricks that lets you operate on Steam's Proton installations. With one or two extras, like the ability to launch through a specific Proton instance.