Package Details: proton-ge-custom 2:GE.Proton9.22-1

Git Clone URL: https://aur.archlinux.org/proton-ge-custom.git (read-only, click to copy)
Package Base: proton-ge-custom
Description: Compatibility tool for Steam Play based on Wine and additional components, GloriousEggroll's custom build
Upstream URL: https://github.com/GloriousEggroll/proton-ge-custom
Keywords: dxvk proton steam valve vkd3d wine
Licenses: custom
Provides: proton
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 41
Popularity: 3.11
First Submitted: 2020-03-23 23:52 (UTC)
Last Updated: 2024-12-30 14:02 (UTC)

Dependencies (117)

Required by (7)

Sources (12)

Pinned Comments

loathingkernel commented on 2023-10-12 10:43 (UTC) (edited on 2023-10-12 10:45 (UTC) by loathingkernel)

@rekman, thank you for looking into CUDA issues, at least it gives me an idea on how to fix it. That being said, my position remains to build it in a clean chroot, away from the locally installed packages. It is not feasible for me to carry patches for the build systems of various subprojects in the long run.

By enabling the 0003-AUR-Remove-kaldi-openfst-vosk-api-modules-because-of patch, you lose voice recognition which I assume is not that big of a loss as I haven't encountered a use for it, so I think it is an acceptable alternative.

patlefort commented on 2022-09-22 00:33 (UTC)

Compilation will fail if you happen to have jwasm installed, due to vulkan loader. Workaround: uninstall jwasm or add this line to prepape() in the PKGBUILD:

sed -i 's/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF -DJWASM_FOUND=0/' "$srcdir/$pkgname/Makefile.in"

loathingkernel commented on 2020-11-21 10:28 (UTC) (edited on 2022-09-13 10:55 (UTC) by loathingkernel)

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.

  • If you are not using CFLAGS and CXXFLAGS specific to your system this package won't offer much in terms of performance as the upstream build flags already target the nocona (Core2) architecture. It will possibly perform worse than upstream. The only benefits you get is not depending on steam linux runtime as well as linking to Arch libraries. If you still want to build it, you can uncomment the relevant lines in the PKGBUILD to enable CFLAGS and CXXFLAGS similar to the upstream.

  • 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.

Latest Comments

« First ‹ Previous 1 .. 22 23 24 25 26 27 28 29 30 31 32 .. 34 Next › Last »

loathingkernel commented on 2021-04-07 10:43 (UTC) (edited on 2021-04-08 14:38 (UTC) by loathingkernel)

@randomguy343 at least until one of the dependencies of afdko gets updated and afdko stops working again. This comment section is littered with reports of version mismatches between what each of these packages expect and what is actually on the system.

Personally, I used to use a python virtualenv and set the environment before building this and the proton-native package but PKGBUILDs are supposed to take care of any environment prerequisites, hence the current solution.

<deleted-account> commented on 2021-04-07 00:01 (UTC)

@loathingkernel Or you could just install afdko and it's missing dependencies python-fontparts and maybe also python-fontparts beforehand manually.

loathingkernel commented on 2021-04-02 05:39 (UTC) (edited on 2021-04-02 06:22 (UTC) by loathingkernel)

@tessaracht there is no such thing as makeotf package, it is part of afdko and as mentioned in the pinned comment there are issues with the AUR package. That is why it is installed through pip on a virtualenv as mentioned with comments in the PKGBUILD. While the solution has not been a "quick fix" it has been worked around already, check your configuration and if pip was able to install the needed packages.

tessaracht commented on 2021-04-02 02:01 (UTC)

current build fails almost immediately in building fonts, looks like makeotf isn't listed as a build dep:

fontforge -quiet -script ../proton-ge-custom/fonts/scripts/generatefont.pe obj-fonts/LiberationMono-Regular.sfd "CourierNew" "Courier New" "Courier New"
makeotf -f ../proton-ge-custom/fonts/source-han-sans/cidfont.ps.OTC.SC -omitMacNames -ff ../proton-ge-custom/fonts/source-han-sans/features.OTC.SC \
    -fi ../proton-ge-custom/fonts/source-han-sans/cidfontinfo.OTC.SC -mf ../proton-ge-custom/fonts/patches/YaHei-FontMenuNameDB -r -nS -cs 25 -ch ../proton-ge-custom/fonts/source-han-sans/UniSourceHanSansCN-UTF32-H \
    -ci ../proton-ge-custom/fonts/source-han-sans/SourceHanSans_CN_sequences.txt -o ./obj-fonts/SourceHanSansSCRegular.otf
/bin/bash: line 1: makeotf: command not found
make[1]: *** [../proton-ge-custom/build/makefile_base.mak:2048: obj-fonts/SourceHanSansSCRegular.otf] Error 127

should be a quick fix to add it.

<deleted-account> commented on 2021-03-19 15:28 (UTC)

@loathingkernel Okay, that worked and the directory was correctly created, thanks and sorry for my comment.

loathingkernel commented on 2021-03-19 15:01 (UTC) (edited on 2021-03-19 15:02 (UTC) by loathingkernel)

@randomguy343 Try rebuilding it without an AUR helper and report back please. I can't make any assumptions or even guesses with the information you have provided thus far.

<deleted-account> commented on 2021-03-19 13:26 (UTC)

The installation fails without an error for me, my AUR helper doesn't show the package as installed and the install directory according to the PKGBUILD (/usr/share/steam/compatibilitytools.d) is empty. What am I missing?

loathingkernel commented on 2021-02-20 20:18 (UTC) (edited on 2021-02-20 20:19 (UTC) by loathingkernel)

@class101

  • mingw-w64-tools offers widl which is required to build vkd3d-proton, it is also offered by wine, but mingw-w64-tools is smaller and is the proper tool.
  • lib32-gsm is the x86 counterpart of gsm and is required for equality between the x86 and x86_64 builds of wine.

class101 commented on 2021-02-20 20:07 (UTC) (edited on 2021-02-20 20:10 (UTC) by class101)

Not sure why aur/mingw-w64-tools and aur/lib32-gsm are required. As it compiles fine without them.

I think if possible, it is best to use the less aur packages possible especially with dependencies.

I have the following installed

  • community/mingw-w64-winpthreads
  • community/mingw-w64-headers
  • community/mingw-w64-gcc
  • community/mingw-w64-crt
  • community/mingw-w64-binutils
  • extra/gsm

loathingkernel commented on 2021-02-05 14:42 (UTC) (edited on 2021-02-06 00:05 (UTC) by loathingkernel)

@PedroHLC Great to hear it is working now. Anything else you need, feel free to contact me.

@orlfman So, I downloaded the GOG version and tested it. Works fine here. Unless you can provide some more info, I am afraid I cannot investigate more. I used the current version and launched the game in an env that resembles the env proton sets up. How do you launch the game? What else have you tried?

Edit: On second launch it does get stuck. This gets us somewhere, ok.

Edit2: The game plays the in-game videos fine if you disable the intro videos in the settings. I can't really understand what is going on and why sometimes it plays the intros ok and sometimes it gets stuck.

« First ‹ Previous 1 .. 22 23 24 25 26 27 28 29 30 31 32 .. 34 Next › Last »