Arch Linux User Repository

Notes about this package

• If you encounter issues while using this package, please contact me here first before reporting an issue to the upstream repository. Don't post logs, link to them. If you are using Manjaro, another derivative or an AUR helper, please mention it, I DO NOT TEST AGAINST THEM AND I CANNOT KNOW WHAT MIGHT BE WRONG WITH THE DISTRO/HELPER OF YOUR CHOICE.

• It takes a LOT of time and space to build. Building with multiple jobs helps but might cause builds to fail in rare cases. Be sure to have at least 16GB of RAM if you are building on tmpfs

• It is NOT built against Steam Linux Runtime (Sniper, Soldier, etc) and as such it doesn't require it. Still, is detected by Steam and works properly (preferable through steam-native).

• This PKGBUILD uses CFLAGS, CXXFLAGS and LDFLAGS hardcoded in the PKGBUILD itself. By default it uses the same C[XX]FLAGS as upstream, namely -march=nocona and -mtune=core-avx2. To change them you will have to edit the PKGBUILD itself. Due to the nature of this package some flags can cause it to fail to build or not function properly. I try to filter them out but it is based on testing. If you have a feeling that compile-time options are involved in the issues you are having please include them in your comment. Currently the filtered options are -fstack-protector-{,-strong,-all}(dxvk and vkd3d only), -fno-plt, -z,relro, -z,now. Also the use of AVX instructions is disabled through -mno-avx.

• There have been reports with afdko failing to find its dependencies during building. I can't do anything about that as I don't maintain that package. It is NOT an issue with this package and I haven't found a way to not depend on it. Please don't report fails due to afdko (or any of its python- dependencies, they are pulled in due to afdko and only used by that), it has been discussed enough. There are possible workarounds in the comments.

• It contains a patch to store game prefixes in the main Steam Library under $HOME/.local/share/Steam/steamapps/compatdata. It helps with isolation of game prefixes between users and works around issues with shared libraries on NTFS partitions due to drive symlinks. To enable it, set the PROTON_USER_COMPAT_DATA env variable to 1.

• This package requires a Rust 32 bit target, please run rustup target install i686-unknown-linux-gnu BEFORE posting any issues if you're using rustup.

Seems like there is a build dependency issue, because whenever I try to build proton through pikaur it's having issues with the fact that there is no package called openvr and wine-valve Checking now if installing the packages with the '-git' appended fixes the issue

@Kiwii as far as I can tell, vrclient depends on headers which are not present in other versions of wine.

@Tom_B, at this time, the package only builds lsteamclient.dll.so (in 32 and 64 bit), not Wine or the Proton run script.

From my understanding, this should be the library that allows a game run in regular Wine to communicate to the native Steam client, but I couldn't figure out how to set it up either. (And I lost my motivation to tinker with it when Valve updated Proton's Wine to 3.16)

Am I being stupid here? I've installed the package but don't know how to execute it:

$ proton bash: proton: command not found

$ wine --version wine-3.16 (Staging)

which is the version I already had installed. How do I launch proton?

What's the required setup to make an application in a prefix be able to use this lsteamclient.dll.so to communicate with the native Steam client?

Do I have to copy the stuff from the native Steam client's legacycompat directory somewhere into the prefix or the game folder?

@Forty-Bot,

It would be difficult to replace the built-in version of proton which comes with steam. I will look into it when I've managed to integrate all existing components.

That comment seems to disagree with what Valve has written in their blog on 21 Aug 18 here: https://steamcommunity.com/games/221410/announcements/detail/1696055855739350561

If you're familiar with building open source projects, you can even make your own local builds of Proton; the Steam client has support for using those to run games in lieu of the built-in version...

Proton is built on top of a modified version of wine.

Correct.

This modified version of wine uses a library that is not built in any other version of wine, so proton won't work with other wine versions

vrclient depends on a header file which isn't present. I don't know if there is any additional functionality beyond that which isn't in standard wine.

You're planning to isolate this library (vrclient) so this package can be built with any wine version?

No. As Proton needs a custom version of wine, it currently can only be built with valve's wine patches. If these get merged upstream, then it is possible it could be built with other versions of wine in the future.

Also, once this package is compiled, how do I make Steam Play utilize it?

It would be difficult to replace the built-in version of proton which comes with steam. I will look into it when I've managed to integrate all existing components.

@Forty-Bot So let me get this straight. Proton is built on top of a modified version of wine. This modified version of wine uses a library that is not built in any other version of wine, so proton won't work with other wine versions. You're planning to isolate this library (vrclient) so this package can be built with any wine version? I hope that is the case, because I'd really like to test this out with wine-staging. Also, once this package is compiled, how do I make Steam Play utilize it?

According to https://github.com/ValveSoftware/Proton/blob/proton_3.7/CHANGELOG.md the latest version should work with both python2 and python3

I'll see if I can. The ./proton seems like the only part written in python; depending on how much needs to be changed, I could just rewrite it...