Registering wine-proton as a separate Proton within Steam

[lox-enterprises]

When installing Proton locally (https://github.com/ValveSoftware/Proton#install-proton-locally) and replacing the locally built one with wine-proton, it gets listed separately in Steam (more details here: ValveSoftware/Proton#727 (comment)).

Important for the listing are:

• the directory compatibilitytools.d within the ~/.steam/steam folder, in this directory you place the Proton folder, ie. proton-wine (when building Proton locally, it defaults to proton-localbuild)
• a file named compatibilitytool.vdf within the aforementioned Proton folder

The contents of compatibilitytool.vdf are like so:

"compatibilitytools"
{
  "compat_tools"
  {
    "proton-localbuild" // Internal name of this tool
    {
      // Can register this tool with Steam in two ways:
      //
      // - The tool can be placed as a subdirectory in compatibilitytools.d, in which case this
      //   should be '.'
      //
      // - This manifest can be placed directly in compatibilitytools.d, in which case this should
      //   be the relative or absolute path to the tool's dist directory.
      "install_path" "."

      // For this template, we're going to substitute the display_name key in here, e.g.:
      "display_name" "Proton 4.0 RC3"

      "from_oslist"  "windows"
      "to_oslist"    "linux"
    }
  }
}

To note, I don't know if the make install for building Proton locally does any priming of Steam, perhaps it is enough to create the compatibilitytools.d folder and compatibilitytool.vdf file.

[sputniktr02]

@1202software Hi, creating the folder compatibilitytools.d and compatibilitytool.vdf file seems to be enough to make it appear in the list. However proton-wine is not working for me, whether it is installed as an existing proton or this way. Games does not start and it creates an empty prefix in compatdata folder for me. I have tried last two release.

[kakra]

I can only guess you did not extract my archive into an existing Proton folder...

So, first try to copy an existing Proton version to the compat folder (3.16 Beta preferred) and try if that works. If it does, cd into that directory (where the "proton" script is) and extract my archive:

cd path/to/compat/tool/directory
tar xf ~/downloads/wine-proton_3.16-4.0-rc7.tar.xz

Also, please check the logs (you may need to turn on logging in user_settings.py, but please don't use full logging, fixme+all is enough for me (and won't have a performance impact). The logs can be found in your home directory, one log per Steam gameid.

I will come up with a more detailed solution later but it will take some time.

[sputniktr02]

@kakra Hi, thanks for the help, it worked.
I just created compatibilitytools.d folder in ~/.steam/steam and then
created a folder proton-wine in that directory and created compatibilitytool.vdf in it.
Then i put proton-3.16-beta files in it and installed your version on top of it and overwrote everything.
Now i can select proton-wine from the list, i have tried couple of games and it seems to be working.

Keep up the good work man. Peace.

[lox-enterprises]

@kakra Above steps, the copying, unpacking and creating the compatibiltytools.d folder + compatibilitytool.vdf file, could this be put into a shell script, which you could distribute with proton-wine? That would make it easy and useful for a larger crowd, I think.

[kakra]

@1202software My plans are a little different: I'm working on expanding my build scripts to create a self-contained version of proton which doesn't need the official binary Proton as a base version. But yes, in the end there will be an installer script which creates the compat folder.

It's currently missing some pieces like building a minimal ffmpeg version etc. I didn't work on that specific detail yet because ffmpeg binary distribution and licensing is unclear (ffmpeg may include codecs that you may not distribute binary). OTOH, maybe it could work just without it by using system-ffmpeg.

[ahjolinna]

@kakra : any progress with this?
and about the ffmpeg thing, I don't think having a build-in ffmpeg with those "problematic" codecs really matters for minor/personal usages, it's only more of an issue for enterprise side (in USA), but if you really care about the licensing just go with system-ffmpeg. Also what the required codecs that are "problematic? as some have opensource version or/and their licensing are EOL

[kakra]

There's some progress, a basic binary builds, proof of concept needs yet to be implemented but due to personal circumstances this will be on hold for at least 2 weeks from now. I also won't be able to work on the branch currently for the same reasons. :-(

[ahjolinna]

sad to hear, hopefully everything will be back to normal soon...as for the codec thing any thoughts about that? could you say at least what are the codecs in question so it's possible to look in too the situation more closer.

[kakra]

Currently, my version uses system-ffmpeg. My plan on this will handle this properly, I think.

I think it's about non-open codecs like WMV or MP3. But I think it's better to solve this by not shipping ffmpeg at all instead of bundling a limited version, then at least system-ffmpeg can have those codecs. Only problem that way with ffmpeg is its unstable ABI and versioning. I think it's okay to distribute those codecs in non-binary form (as source code). So everyone could just build her/his own version. Maybe I'll include instructions or a template for that.

[ahjolinna]

Yeah I agreet on the ffmpeg abi thing, I have been vocal about this issue. What it comes laws distribution on these codes, you are allowed to use them for personal/non-enterprise purposes only.. otherwise you need to pay.

At least mp3 patents has went EOL so it won't be a problem, but I don't now remember the status of WMV/WMA... Easiest way to check this is what Fedora is shipping by default, as they follow the US patent laws more carefully than others (because RedHat)

[kakra]

The problem I'm having with this: While I'm not Valve (and neither associated with them in any way), this is probably still not strictly a private project because it's to be bundled with Proton. So the best plan is staying with system-ffmpeg or whatever people provide by themselves.

[ahjolinna]

well what I just checked at least those codec patents have went EOL, well okay WMV/AV1 has lost over half (but there are so many owners and major ones went EOL)...at least mainstream distros (and most "minor" ones) don't find distributing them by default problematic, so by my logic if it's fine by them this shouldn't be a problem for us.....well up to you anyways

I do wonder what you will do when next major ffmpeg version arrives, as some LTS distros are going to be on v3 and it will take while for some non-lts distros that aren't rolling to update from v4 to the next major one (that breaks the ABI again)

I don't know if you know/use mpv but they have something called mpv-build, it's a script that builds a statically linked ffmpeg for you.

[kakra]

I think currently this is a non-issue... At least for my system (and I expect people to report issues if their system doesn't work with it). Let's look into ffmpeg-issues when time comes. A lot of licensing stuff may settle until then.

My launcher-in-spe supports layering of multiple Proton-compatible dist-archives. One of such archives could be a custom-built or separately built ffmpeg version. As such, I don't see many problems for this.

I'm currently back up with a somewhat limited work environment to continue working on this but I will be focusing on rebasing to wine-4.2 first (there seem to be some conflicts that need proper investigation, otherwise compilation fails or wine crashes).