Support compatibility tools other than Proton out-of-the-box.

[loathingKernel]

This PR aims to allow auto-configuration of compatibility tools other than Proton by using the information in compatibilitytool.vdf and toolmanifest.vdf manifest files. Using this information umu can construct the proper command for each tool based on which runtime the tool depends on (if at all), the entry point of the runtime and the tool, and the type of the tool (important for winetricks as it works only on proton). This supersedes environment variables such UMU_NO_PROTON (PROTONPATH remains as a way to set the tool with expanded meaning) and UMU_NO_RUNTIME. These variables are retained only to force a specific configuration if required.

For example GAMEID=0 WINEPREFIX=~/Wine/umu/ UMU_LOG=debug PROTONPATH=luxtorpeda umu-run launches luxtorpeda through umu.

• Important changes:

  • vdf library is now a vendored dependency. It is a pure-python library and thus compatible with zipapp.
  • UMU_NO_PROTON renamed to UMU_NO_TOOL to avoid confusion of its purpose. This is useful if the user wants to run a linux-native binary in the runtime without a tool.
  • UMU_NO_RUNTIME is retained as an override if the user wants to explicitly disable the runtime even if the tool requires it. Tools that don't use the runtime do not require this to be set any more.
  • umu checks if the configured tool is a proton-derived tool when using winetricks and exits if it is isn't.
  • umu-shim is always prepended to the tool's command. I have not tested this extensively but it didn't cause issues while testing with various tools and protons under X11.

• Things that need more consideration:

  • umu renames _v2-entry-point to umu. This rename is handled here. The same name for the entry point is also used in the soldier, streamrt2 runtime. The "new" scout-in-soldier runtime uses scout-on-soldier-entry-point-v2. If umu was to stop renaming the runtime's entry point, it should make supporting more runtimes easier.
  • Related to the above considering scout-in-soldier, it is a runtime which depends on another runtime. The current implementation of SteamRuntime class doesn't handle a runtime using another runtime. Should it be implemented and remain unused for now?
  • Related to both of the above and the UMU_NO_TOOL env variable. The PROTONPATH env variable could be used to define the runtime that should be used to run a linux-native executable in the form of PROTONPATH="soldier/scout/etc". This should make UMU_NO_TOOL obsolete.
  • umu-shim is always prepended to the tool's command. I have no tested this extensively but it didn't cause issues while testing with various tools and protons.

Marked as draft for now pending the first round of reviews.

[beh-10257]

will this make it possible to use proton-tkg ??
sorry if this is early days

[loathingKernel]

will this make it possible to use proton-tkg ?? sorry if this is early days

It should make possible to run any tool that works with Steam as a compatibility tool. The main constraint not addressed yet are tools that require a runtime other than sniper but I consider support for multiple runtimes a superset which is not going to be addressed by this PR alone.

[R1kaB3rN]

Yeah I guess it all boils down to whether supporting more compatibility tools is something we want to support, and all think will be very useful to enable for users. Right now, I’m observing users are satisfied with the experience of just running their games through Proton. I haven’t seen any reports/stories of users/clients wanting more than that, unless you can bring up a few cases where they did? So I would kind of like to have more folks chime in with their thoughts, and maybe wait a bit.

Utility aside, in the case of winetricks, I think this would allow us to take out the winetricks code we have in both umu and Proton, and make it a tool instead. That architectural change, sorta makes it attractive but at the cost of some parsing overhead and introducing another point a failure at launch for something we don’t directly control (yet). On the other hand, we could just make the tools native properties of the runtime. This avoids the mess of parsing and figuring out the correct runtime all together. If the tool isn’t large as Proton, it shouldn’t be a problem.

Also, on the topic of compat tools, I actually view supporting only 2 compatibility tools (SLR and Proton) as an advantage we have over Steam, which has to deal with the backward compatibility hell. Hence, they continue (and will forever) to support/keep obsolete runtimes and come up with solutions like nesting scout in soldier. With umu, we have the opportunity to avoid some of those decisions and come up with better solutions instead for certain areas. To me, I think keeping it simple by maintaining 1 runtime, while keeping but not updating old ones, and running both Linux/Windows executables is one of those areas.

[loathingKernel]

Right now, I’m observing users are satisfied with the experience of just running their games through Proton. I haven’t seen any reports/stories of users/clients wanting more than that, unless you can bring up a few cases where they did?

A few I can gather from different projects are below. I am pinging @imLinguin since they also have expressed interest in this feature and they could provide more use-cases and user requests.

Boxtron in Heroic
Luxtorpeda in Rare
Proton-CachyOS with Lutris

and maybe wait a bit.

Certainly because this is an invasive architectural change if we want to do it properly and should be done in a way that makes sense for everyone.

Utility aside, in the case of winetricks, I think this would allow us to take out the winetricks code we have in both umu and Proton, and make it a tool instead.

This is indeed an interesting proposition, but I have not considered it yet, simply because winetricks is inherently tied to proton and wine. It does require of a wine to be present in the process and to me that is simpler to exist as it does now, a script provided by umu-protonfixes.

On the other hand, we could just make the tools native properties of the runtime. This avoids the mess of parsing and figuring out the correct runtime all together. If the tool isn’t large as Proton, it shouldn’t be a problem.

I do not agree with where this proposition is headed. I do not think we should alienate external tools or confuse the users with home-brew alternatives for things they already might be using. For me umu's mission is to unify what already exists for Steam, and make it available for other launchers, not be yet another choice clustering the space even more. For better or worse, it does tie umu to parsing and using the same attributes that Steam uses, but that's what it does already in other regards.

Also, on the topic of compat tools, I actually view supporting only 2 compatibility tools (SLR and Proton) as an advantage we have over Steam, which has to deal with the backward compatibility hell. Hence, they continue (and will forever) to support/keep obsolete runtimes and come up with solutions like nesting scout in soldier. With umu, we have the opportunity to avoid some of those decisions and come up with better solutions instead for certain areas. To me, I think keeping it simple by maintaining 1 runtime, while keeping but not updating old ones, and running both Linux/Windows executables is one of those areas.

@imLinguin has demonstrated some interesting aspects of scout-on-soldier already by using it to run older native game from GOG, thus such an effort brings forth an opportunity to be useful towards those stores in keeping their existing native ports usable.

Another example is, IIRC, Helldivers which was not playable on recent proton versions but required some old version which was based on soldier to run. Using that version is not currently possible with umu due to different runtime requirements. Similarly this is likely to happen once medic starts rolling out.

Overall I do not consider constraining umu to two compatiblity tools beneficial, and since the difficult part of maintaining these runtimes doesn't fall on umu, I would consider it a net gain.