Install Lutris, Heroic and GE-Proton on Fedora 45 / 44

GE-Proton is not a Wine build you unpack and point a launcher at anymore. Outside Steam, GloriousEggroll only supports it under umu-launcher, which runs Proton inside the same Steam Linux Runtime container Steam uses, and both Lutris and Heroic now set that up on their own. So getting GE-Proton on Fedora comes down to installing a launcher and knowing what it fetches the first time you press Play.

Original content from computingforgeeks.com - post 177747

This guide checks Vulkan first, installs Lutris from the Fedora repo and Heroic from Flathub, makes GE-Proton the default in both, pins builds with ProtonUp-Qt, and runs OpenTTD through each launcher, with every error we hit and its fix. The lab VMs had no GPU, so this proves the setup and the failure modes rather than frame rates. Everything below was run on Fedora 45 in October 2026 with Lutris 0.5.22, Heroic 2.22.4, ProtonUp-Qt 2.16.0 and GE-Proton11-11, and the Lutris install was repeated on Fedora 44.

GE-Proton runs through umu, not Wine

When you press Play on a Windows game in Lutris or Heroic with GE-Proton selected, the launcher does not call wine. It calls umu-run, and umu builds the same environment Steam would build for a Steam game. A launch passes through four layers, in this order:

1. The launcher, Lutris or Heroic, with your game settings.
2. umu-run, which fetches anything missing.
3. The steamrt4 runtime container, started by srt-bwrap.
4. The proton script inside GE-Proton, then the game.

The launcher picks the GE-Proton build, the prefix and the executable. umu downloads GE-Proton and the Steam Linux Runtime when they are missing, and the runtime gives Proton its own libraries. So what does that mean for you on Fedora? The first launch puts about 2.5 GB on disk on top of the launcher, prefix included, because GE-Proton and the runtime aren’t Fedora packages. The container still uses your host’s graphics driver, so the Mesa or NVIDIA packages on Fedora matter as much as they do for Steam. And the GE-Proton README is blunt about the old way. Running the tarball from a Wine runner directory without umu isn’t supported. Wine then falls back to whatever libraries your distro happens to ship.

You do not install umu-launcher yourself. The Fedora repos don’t carry it (dnf list "umu*" found no match on Fedora 45), and you don’t need them to, because Lutris downloads its own copy into ~/.local/share/lutris/runtime/umu on first start, and Heroic downloads its own the first time you launch a game. If you only use Steam, none of this applies; the Steam, Proton and NTSYNC setup for Fedora covers that path and the GPU driver side.

vulkaninfo proves the 64-bit driver first

Proton translates Direct3D into Vulkan through DXVK and VKD3D-Proton, so a game gets only as far as your Vulkan driver lets it. Check that driver before you install a launcher, because neither one explains a broken driver well: Lutris greys out DXVK, and Heroic writes a warning to a log you probably won’t open. vulkaninfo comes from the vulkan-tools package:

sudo dnf install -y vulkan-tools
vulkaninfo --summary

On our Fedora 45 Cloud VM this was the first failure. vulkan-tools installed six packages and none of them was the Vulkan loader, so the tool stopped before it looked for a GPU and exited with status 1:

ERROR at /builddir/build/BUILD/vulkan-tools-1.4.350.0-build/Vulkan-Tools-vulkan-sdk-1.4.350.0/vulkaninfo/./vulkaninfo.h:564: Failed to initialize: Vulkan loader is not installed, not found, or failed to load.

So installing vulkan-tools proves nothing by itself: on Fedora 45 the package does not depend on the loader, and our Cloud image had neither. Check your own system before assuming a desktop install shipped the full stack.

Failed to initialize: Vulkan loader is not installed, not found, or failed to load

This error is about libvulkan.so.1, not your graphics card. rpm -q vulkan-loader mesa-vulkan-drivers printed is not installed for both, and /usr/share/vulkan/icd.d/ did not exist, so there was no loader and no driver for it to load. You don’t need to install the loader by name. Mesa’s Vulkan drivers depend on it:

sudo dnf install -y mesa-vulkan-drivers

That pulled nine packages, among them vulkan-loader and llvm-libs, for 327 MiB on disk. Run the summary again, this time keeping only the three lines that tell you which driver a game will get:

vulkaninfo --summary 2>/dev/null | grep -E "deviceName|driverName|apiVersion"

With no GPU in the VM, the only device was Mesa’s software rasterizer:

	apiVersion         = 1.4.354
	deviceName         = llvmpipe (LLVM 23.1.0, 256 bits)
	driverName         = llvmpipe

Each of the three lines answers one question:

• deviceName: the device games will render on
• driverName: the Vulkan driver that answered
• apiVersion: the newest Vulkan that device supports

Read deviceName first. llvmpipe renders on the CPU, which is how we could run and screenshot everything in this guide on a VM, and also why there are no frame rates here. On your machine that line has to name your graphics card. If it says llvmpipe on a desktop with a real GPU, the hardware driver isn’t loading, and games will crawl instead of failing, which is harder to notice than an error. AMD and Intel cards get their drivers from this same mesa-vulkan-drivers package (its radeon_icd and intel_icd files), while NVIDIA cards need the RPM Fusion driver. Still choosing hardware? The GPU guide for Linux gaming compares cards by how well their drivers behave on Linux.

ERROR: [Loader Message] setup_loader_term_phys_devs … libvulkan_powervr_mesa.so failed with error code -3

The working run still printed warnings and two ERROR lines on stderr before the summary, which is why the command above sends stderr to /dev/null. Run it without the redirect and you’ll see lines like these:

WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Received return code -9 from call to vkCreateInstance in ICD /usr/lib64/libvulkan_dzn.so. Skipping this driver.
WARNING: [../src/imagination/vulkan/pvr_instance.c:75] Code 0 : Failed to enumerate drm devices (errno 2: No such file or directory) (VK_ERROR_INITIALIZATION_FAILED)
ERROR: [Loader Message] Code 0 : setup_loader_term_phys_devs: Call to 'vkEnumeratePhysicalDevices' in ICD /usr/lib64/libvulkan_powervr_mesa.so failed with error code -3

Mesa installs one ICD file per driver it ships, twelve on x86_64 here, and the loader tries every one of them. Dozen (dzn, Vulkan on Direct3D 12 for WSL) and the PowerVR driver find no hardware they support and get skipped. They’re noise as long as the device list after them names your card. vulkaninfo also only exercises the 64-bit loader. The 32-bit half, which Lutris checks separately, is covered right after the Lutris install.

Lutris installs from the Fedora repo

Lutris is in the main Fedora repo, so there is no COPR or third-party repo to add, and updates arrive with the rest of the system through dnf upgrade. The package also recommends Wine, GameMode, gamescope and the 32-bit graphics libraries, which dnf installs by default:

sudo dnf install -y lutris

On a Fedora Cloud base with no desktop packages, the transaction was large. The summary below is from the first test VM, where the one replaced package came from updates-testing and does not matter for Lutris:

Transaction Summary:
 Installing:       413 packages
 Replacing:          1 package
 Downgrading:        1 package

Total size of inbound packages is 634 MiB. Need to download 634 MiB.
After this operation, 3 GiB extra will be used (install 3 GiB, remove 4 MiB).

It took 2 minutes 33 seconds. Do you run Workstation? It already has most of those libraries, so your transaction will be smaller. Confirm the version once dnf finishes:

lutris --version

Fedora ships the current upstream release:

lutris-0.5.22

If the version prints but the window never opens, the next error is the likely reason.

TypeError: expected str, bytes or os.PathLike object, not NoneType

Lutris crashed before drawing its window on the first start. The log line just above the traceback names the cause, Command 'xrandr' not found on your system. Lutris reads screen resolutions through the xrandr binary, the package doesn’t list it as a dependency, and the call passes None to subprocess when it is absent. Minimal and Cloud-based installs do not have it. Install it and start Lutris again:

sudo dnf install -y xrandr pciutils

pciutils is there because Lutris also logged Command 'lspci' not found, which it uses to identify your GPU. Neither package is needed by anything else in this guide.

Lutris needs the 32-bit Vulkan loader

Lutris decides whether DXVK is available by checking for both the 64-bit and the 32-bit libvulkan.so.1. If the i686 loader is missing, the DXVK toggle goes grey and the Runner options tab shows an error, even when vulkaninfo lists a working device. That’s what happened on our first VM:

The cause was the VM, not Lutris. Its 64-bit Mesa had come from updates-testing, so no i686 build in the stable repos matched the installed version, and dnf quietly dropped the 32-bit Recommends instead of failing. The second VM, whose Mesa came from the stable repos, installed 659 packages for the same dnf install lutris, 208 of them i686. Check which case you’re in before you change anything:

rpm -q vulkan-loader.i686 mesa-vulkan-drivers.i686 mesa-dri-drivers.i686 mesa-libGL.i686

Any line that says is not installed means Lutris will refuse DXVK. Install the four packages explicitly:

sudo dnf install -y vulkan-loader.i686 mesa-vulkan-drivers.i686 mesa-dri-drivers.i686 mesa-libGL.i686

On the updates-testing VM this pulled 37 packages and downgraded 18 64-bit Mesa packages to the stable versions so both architectures match. The VM we built for this refresh hit the same wall one layer lower: its glibc and systemd had come from updates-testing, so vulkan-loader.i686 mesa-vulkan-drivers.i686 alone installed 28 packages and downgraded 18, glibc 2.44-2 back to 2.44-1 among them. Drop -y if you have ever enabled updates-testing, and read the Downgrading list in the transaction summary before you confirm. A system that only takes stable updates has nothing newer to downgrade from. Restart Lutris afterwards, because it checks the libraries once at startup. Do you run an NVIDIA card? Then the 32-bit half of your driver is xorg-x11-drv-nvidia-libs.i686, which the RPM Fusion packages pull in by themselves on current Fedora once 32-bit Mesa or Wine is installed. The NVIDIA driver guide for Fedora covers the driver itself, and rpm -q xorg-x11-drv-nvidia-libs.i686 confirms the 32-bit part is there.

Lutris defaults to GE-Proton (Latest)

Current Lutris already uses GE-Proton for new Wine games, so there’s nothing to switch. Any Windows executable you own works for this section. If you want a free test game, OpenTTD publishes a Windows build and needs the OpenGFX graphics set next to it. These commands look up the current stable releases, then unpack both into ~/Games/openttd:

mkdir -p ~/Games/openttd ~/Downloads
cd ~/Downloads
V=$(curl -s https://cdn.openttd.org/openttd-releases/latest.yaml | grep -B1 "name: stable" | head -1 | awk '{print $3}')
G=$(curl -s https://cdn.openttd.org/opengfx-releases/latest.yaml | grep -B1 "name: stable" | head -1 | awk '{print $3}')
echo "OpenTTD $V, OpenGFX $G"
curl -LO https://cdn.openttd.org/openttd-releases/$V/openttd-$V-windows-win64.zip
curl -LO https://cdn.openttd.org/opengfx-releases/$G/opengfx-$G-all.zip

The echo printed OpenTTD 15.3, OpenGFX 8.0 in our run. Extract the game, flatten its folder, and drop OpenGFX into the baseset directory where the game looks for graphics. Install the 7zip package first if 7z isn’t on your system yet, and run this in the same terminal so $V and $G are still set:

sudo dnf install -y 7zip
cd ~/Games/openttd
7z x -y ~/Downloads/openttd-$V-windows-win64.zip
mv openttd-$V-windows-win64/* . && rmdir openttd-$V-windows-win64
cd baseset && 7z x -y ~/Downloads/opengfx-$G-all.zip

Now add the game to your library. Click the + button at the top left of the Lutris window to open the add dialog:

Pick Add locally installed game. You fill in four fields across the tabs of the form that opens:

1. Game info: name OpenTTD, runner Wine.
2. Game options: the full path to openttd.exe.
3. Game options: a new Wine prefix directory.
4. Runner options: keep GE-Proton (Latest), then Save.

On our VM the executable was /home/kenneth/Games/openttd/openttd.exe and the prefix /home/kenneth/Games/prefixes/openttd, which does not need to exist yet because Proton creates it on the first launch. With the 32-bit loader in place, the Runner options tab shows DXVK enabled and GE-Proton selected by default:

The Wine version list held three entries on a fresh install: Custom, System (11.0 (Staging)) from the Fedora wine-core package, and GE-Proton (Latest). Only the last one goes through umu. The System entry runs the Fedora build of Wine directly, which is the setup our Wine on Fedora guide covers.

The first launch fills 2.5 GB of disk

Double-click the game. You’ll see nothing happen for a while, because umu is downloading GE-Proton and the runtime before Proton creates the prefix. On our VM, 2 minutes 30 seconds passed between the click and the game process starting. Three directories filled up during that wait, and du -sh on each gives the sizes below:

• GE-Proton in ~/.local/share/Steam/compatibilitytools.d, 1.6 GB
• The runtime in ~/.local/share/umu/steamrt4, 703 MB
• The Wine prefix you chose, 234 MB

GE-Proton arrived as a 565 MB tarball and unpacked to 1.6 GB, and the prefix held 234 MB before the game had written anything. umu stores GE-Proton under a Steam path even when Steam is not installed. That’s the same compatibilitytools.d directory a native Steam install reads custom Proton builds from. The process tree while the game ran shows the container in the middle of the chain:

ps -eo pid,args --forest | grep -E "lutris-wrapper|umu-run|srt-bwrap|proton runinprefix|openttd.exe" | grep -v grep

Read it top to bottom. gamemoderun wraps umu because Lutris turned GameMode on by default once the package was present, srt-bwrap is the runtime container, and the Windows executable runs under GE-Proton inside it (lines trimmed to 160 characters):

  14895  |   \_ /usr/bin/python3 /usr/share/lutris/bin/lutris-wrapper OpenTTD 0 0 gamemoderun /home/kenneth/.local/share/lutris/runtime/umu/umu-run /home/kennet
  14897  |       \_ python3 /home/kenneth/.local/share/lutris/runtime/umu/umu-run /home/kenneth/Games/openttd/openttd.exe
  14929  |           \_ /home/kenneth/.local/share/umu/steamrt4/pressure-vessel/libexec/steam-runtime-tools-0/srt-bwrap --args 25 /usr/lib/pressure-vessel/from-
  15054  |               \_ /usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/pv-adverb --prefix=/usr/lib/pressure-vessel/from-host --generate-lo
  15078  |                   \_ python3 /home/kenneth/.local/share/Steam/compatibilitytools.d/GE-Proton11-11-x86_64/proton runinprefix /home/kenneth/Games/opent
  15138  |                   \_ X:\Games\openttd\openttd.exe

OpenTTD then opened its title screen. It also warned no compatible GPU found. Hardware acceleration disabled, which is the lab VM talking: it has no GPU, only Mesa’s llvmpipe. On real hardware that message does not appear.

Later launches skip the download and start in seconds. The runtime and the GE-Proton build stay in place until a newer GE-Proton release appears, and then “Latest” downloads it on the next launch.

Pin a GE-Proton build per game

“Latest” moves often. Heroic’s GE-Proton list showed GE-Proton11-10 and GE-Proton11-11 released on the same day, and a game that runs today can break after the next build. Lutris lists any Proton directory in ~/.local/share/lutris/runners/wine as its own Wine version, so you can freeze one game while the rest follow Latest. Fetch the current tag from the GitHub API first:

GE_VER=$(curl -s https://api.github.com/repos/GloriousEggroll/proton-ge-custom/releases/latest | grep -oP '"tag_name": "\K[^"]+')
echo "$GE_VER"

It printed GE-Proton11-11. Download the tarball and its checksum, verify, and unpack it into the Lutris Wine directory:

cd ~/Downloads
curl -LO https://github.com/GloriousEggroll/proton-ge-custom/releases/download/${GE_VER}/${GE_VER}-x86_64.tar.gz
curl -LO https://github.com/GloriousEggroll/proton-ge-custom/releases/download/${GE_VER}/${GE_VER}-x86_64.sha512sum
sha512sum -c ${GE_VER}-x86_64.sha512sum
mkdir -p ~/.local/share/lutris/runners/wine
tar -xf ${GE_VER}-x86_64.tar.gz -C ~/.local/share/lutris/runners/wine/

We downloaded to ~/Downloads rather than /tmp, which is RAM-backed on Fedora; delete the tarball afterwards. The checksum has to say OK before you extract anything. Ours printed GE-Proton11-11-x86_64.tar.gz: OK. List the Wine directory, because the name in it is exactly what Lutris will show you:

ls ~/.local/share/lutris/runners/wine/

One directory per build you’ve unpacked:

GE-Proton11-11-x86_64

Restart Lutris so it rescans the directory, then right-click your game, choose Configure, and open Runner options. The Wine version list now carries the pinned build above System and Latest:

Select it, save, and launch the game. To prove which build umu received from your launcher, read the environment of the running umu-run process while the game is open:

tr "\0" "\n" < /proc/$(pgrep -f umu-run | head -1)/environ | grep -E "^(PROTONPATH|GAMEID|WINEPREFIX)="

PROTONPATH should point at the pinned directory, not at the Steam path from the Latest run:

WINEPREFIX=/home/kenneth/Games/prefixes/openttd
PROTONPATH=/home/kenneth/.local/share/lutris/runners/wine/GE-Proton11-11-x86_64
GAMEID=umu-default

The same terminal session, with lutris --version and the disk use of the runtime, GE-Proton and the prefix, looked like this:

GAMEID=umu-default means no per-game protonfix applied, because OpenTTD added by hand has no store ID. For games from GOG, Epic and the other stores Lutris connects to, it looks the title up in umu’s game database, and GE-Proton’s protonfixes can then apply per-game tweaks. A pinned build also stops getting those fixes, so move it forward when a newer release fixes your game.

Heroic installs from Flathub

Heroic is not in the Fedora repos. The project publishes a Flathub app and an RPM on its GitHub releases page, and you give up something either way:

• Flatpak: automatic updates, about 3.1 GB with runtimes
• RPM: 370 MB, unsigned, no repo, manual updates

We’d take the Flatpak. It updates with flatpak update or GNOME Software like the rest of your Flatpak apps, while the RPM has no repo behind it and every new release is a manual download. The 3.1 GB is the 623 MB app plus about 2.5 GB of Freedesktop runtimes, which other Flatpak apps share once they’re on disk. Add the Flathub remote if flatpak remotes does not list it, then install Heroic system-wide. The Flatpak and Flathub guide for Fedora explains how Fedora’s own Flathub setup differs, if your remote list looks unfamiliar:

sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install -y flathub com.heroicgameslauncher.hgl

The install took 4 minutes 32 seconds and pulled the app plus the Freedesktop runtime with its 32-bit Compat.i386 and GL32 extensions, which Proton needs inside the sandbox. Check the installed version:

flatpak info com.heroicgameslauncher.hgl | grep -E "Version|Installed"

Flathub carries the same release as GitHub:

       Version: v2.22.4
Installed Size: 623.3 MB

Heroic now shows up in your application menu. The first start is where it makes its own decision about Proton, which the next section after the RPM notes covers.

Flatpak system operation GetRevokefsFd not allowed for user

Our first attempt ran flatpak install without sudo over SSH, and it failed after resolving the runtimes with F: Failed to get revokefs-fuse socket from system-helper: Flatpak system operation GetRevokefsFd not allowed for user. A system-wide install needs permission from polkit, and an SSH session has no polkit agent to ask you for a password. Running the same command with sudo, as shown above, installed cleanly.

Installing the Heroic RPM instead

The RPM route works, with one surprise. On Fedora 45, rpm --eval '%{_pkgverify_level}' prints all, so rpm refuses unsigned packages. The Heroic RPM carries no signature. rpm -K reports digests SIGNATURES NOT OK for it. If you try a direct rpm -U, it stops with package heroic-2.22.4-1.x86_64 does not verify: no signature. dnf still installs it for you, because local files skip the OpenPGP check by default:

cd ~/Downloads
HEROIC_URL=$(curl -s https://api.github.com/repos/Heroic-Games-Launcher/HeroicGamesLauncher/releases/latest | grep browser_download_url | cut -d\" -f4 | grep -E "linux-x86_64\.rpm$")
curl -LO "$HEROIC_URL"
sudo dnf install -y ./Heroic-*-linux-x86_64.rpm

dnf says so in its output, which is the line to look for when you wonder why an unsigned package went in:

Warning: skipped OpenPGP checks for 1 package from repository: @commandline
Complete!

The RPM installs Heroic to /opt/Heroic with a heroic command in /usr/bin. The rest of this guide uses the Flatpak, which keeps its settings, Proton builds and library under ~/.var/app/com.heroicgameslauncher.hgl, so it shares nothing with an RPM install. Pick one.

Heroic downloads Proton-CachyOS first

Heroic does not start with GE-Proton. Within seconds of the first launch, with no Wine version installed, its log showed Start installation of wine version Proton-CachyOS-latest, a 331 MB download we never asked for. Wine Manager confirms it, with the Proton-CachyOS tab open and the download in progress:

Proton-CachyOS is a separate Proton build maintained by the CachyOS team, and letting it finish does no harm. To follow this guide and use GE-Proton, switch to it in three steps:

1. Open Wine Manager and cancel the Proton-CachyOS download if unwanted.
2. Download GE-Proton-latest from the GE-Proton tab.
3. Check Settings, Game Defaults, WINE for the new default.

The GE-Proton tab lists every recent build with its date and size, so you can also pin a specific one here, as with Lutris:

Downloads from GitHub were slow in that window. GE-Proton-latest took 19 minutes 48 seconds at 200 to 500 KB/s. A manual curl of the same file running alongside it was just as slow, while umu had fetched it for Lutris in under two minutes earlier that morning. Leave Heroic open until it finishes. Once it was the only installed version, Game Defaults picked it up on its own:

Game Defaults only apply to games you add or install afterwards. A game that’s already in the library keeps its own Wine version, which you change from that game’s settings page.

Heroic’s sandbox can’t read ~/Games

Heroic exists for Epic, GOG and Amazon libraries, and signing in to any of them fills the library. For a game you already have on disk, ADD GAME on the Library page does the same job as the local install in Lutris. The Flatpak can read only a few places in your home directory, though: ~/Games/Heroic, Documents, Desktop, ~/.steam, ~/.local/share/lutris, plus /mnt, /media and /run/media for second drives. Plain ~/Games isn’t one of them, so copy the game under ~/Games/Heroic first. This uses the OpenTTD folder from the download block in the Lutris section; if you skipped Lutris, run that block first. ~/Games/Heroic exists once Heroic has started once.

cp -a ~/Games/openttd ~/Games/Heroic/OpenTTD

Then click ADD GAME and fill in the form from top to bottom. Heroic fetched cover art for OpenTTD by itself:

1. Game/App Title: OpenTTD.
2. Platform: Windows.
3. Wine settings: suggested prefix, GE-Proton-latest.
4. Executable: ~/Games/Heroic/OpenTTD/openttd.exe, then FINISH.

The filled form looked like this before we clicked FINISH:

Press the green play button on your game card. Heroic downloaded umu into its own tools/runtimes/umu directory on this first game launch, and umu then logged Running 'GE-Proton11-11-x86_64' using runtime 'steamrt4', and it reused the runtime Lutris had already downloaded, because the Flatpak is allowed to write ~/.local/share/umu. GE-Proton itself is not shared. Heroic keeps its own 1.6 GB copy in ~/.var/app/com.heroicgameslauncher.hgl/config/heroic/tools/proton, because Heroic installs its Proton builds under its own tools directory by design, and the sandbox can’t see ~/.local/share/Steam unless a native Steam install links it through ~/.steam.

Same game, same GE-Proton build, a second launcher. The difference shows up as soon as the game lives anywhere else.

No available language packs (invalid versions?)

We added the untouched copy from ~/Games/openttd as a second entry. The file picker accepted it, but the path it handed Heroic was /run/user/1001/doc/kDauo_6Jb871BxQdy79v2Q/openttd.exe. That’s the Flatpak document portal, which exports the single file you picked and nothing next to it. OpenTTD started, found no lang folder beside its executable, and stopped:

Any game you add this way that loads data files from its own folder fails the same way, each with its own error. You can either keep games under ~/Games/Heroic, or give the Flatpak read access to the folder that holds them:

flatpak override --user --filesystem=~/Games com.heroicgameslauncher.hgl

The override only applies to a new sandbox, so stop every Heroic process before you start it again and add the game once more:

flatpak kill com.heroicgameslauncher.hgl
flatpak override --user --show com.heroicgameslauncher.hgl

The second command should print filesystems=~/Games;. After the restart the picker returned the real path, /home/kenneth/Games/openttd/openttd.exe, and OpenTTD started normally. Use the narrowest folder that holds your games rather than --filesystem=home.

ProtonUp-Qt installs fixed builds for both launchers

Both launchers fetch GE-Proton on their own, but what they fetch is a moving target: Lutris tracks GE-Proton (Latest) and Heroic’s Wine Manager writes a folder called GE-Proton-latest. The pin section above froze one build with a tarball, a checksum and tar. ProtonUp-Qt does the same download and unpack from a window, for either launcher, and names the folder after the exact release, so a game you pin never moves when the next GE-Proton ships. It isn’t packaged for Fedora. dnf search protonup printed No matches found on Fedora 45, so install it from Flathub, the remote you already added for Heroic:

sudo flatpak install -y flathub net.davidotek.pupgui2

The install took 1 minute 33 seconds, most of it the KDE Platform 6.10 runtime it runs on. Confirm the version you got:

flatpak info net.davidotek.pupgui2 | grep -E "Version|Installed Size"

Flathub had the same release as the ProtonUp-Qt releases page:

       Version: 2.16.0
Installed Size: 308.7 MB

Its Flatpak permissions already cover ~/.local/share/lutris/runners and Heroic’s tools folder, so it needs no overrides. Start it from the app menu or with flatpak run net.davidotek.pupgui2. The first field, Install for, lists every launcher it found along with the folder it writes to, and Heroic shows up twice:

Each entry is a different folder, and only two of them suit GE-Proton:

1. Lutris: ~/.local/share/lutris/runners/wine/
2. Heroic Wine Flatpak: tools/wine/, for plain Wine builds
3. Heroic Proton Flatpak: tools/proton/, where GE-Proton belongs

The Lutris target is the same runners/wine folder the pin section used, so a build installed there runs through umu exactly like the hand-unpacked one. Pick the launcher, click Add version, and leave Compatibility tool on GE-Proton. The Version list starts at the newest release, GE-Proton11-11 during our test:

For Lutris the tool list had ten entries, with Proton-CachyOS, Kron4ek’s Wine builds, Lutris-Wine, DXVK and vkd3d-proton after GE-Proton. Installing GE-Proton11-11 took about three minutes for Lutris and under a minute and a half for Heroic over our lab link, and each copy is 1.6 GB on disk. ProtonUp-Qt names the folder GE-Proton11-11-x86_64 for both, the same name the tarball unpacks to, so it never collides with Heroic’s own GE-Proton-latest. If you already pinned that build by hand for Lutris, there is nothing to install. The Heroic list afterwards marks builds no game uses yet:

Proton-CachyOS-latest is the build Heroic downloaded on first launch, and dxvk-3.1.1 and vkd3d-proton-2.14.1 came with it. That (unused) tag is the cleanup tool you didn’t know you had. Select a build and click Show info: the dialog lists the games set to it, and Remove selected deletes it. The count only covers per-game settings, though. Proton-CachyOS-latest showed as unused here while it was still Heroic’s default in Settings, Game Defaults, so check that page before you remove the build it names. At 1.6 GB a build, the cleanup is worth it.

Start Lutris after the install, or restart it if it was open, since it scans the folder at startup. Open Preferences, then Runners, click the wrench next to Wine, and open the Wine version list on the Runner options tab:

The ProtonUp-Qt build is listed right under GE-Proton (Latest) (default), above the system Wine 11.0 Staging. Leave the runner default on Latest and choose the fixed build per game, in that game’s own Runner options, so one stubborn title doesn’t hold every other game back.

Heroic lists the same GE-Proton build twice

After both installs, Heroic’s Settings, Game Defaults, Wine Version list showed GE-Proton11-11-x86_64 twice, once with the GE-Proton icon and once with a wine glass. Heroic’s sandbox can read ~/.local/share/lutris, and Heroic scans Lutris’s wine folder for builds, so the copy ProtonUp-Qt put there for Lutris shows up in Heroic too. We proved which was which by moving the Lutris folder away and restarting Heroic. The wine glass entry vanished, and the GE-Proton icon entry stayed:

Pick the entry with the GE-Proton icon, the copy in Heroic’s own tools/proton folder, and leave the Lutris copy, wine glass icon and all, to Lutris. Heroic adds every folder in Lutris’s wine directory as a plain Wine build, which in Heroic’s source means it expects a bin/wine inside. GE-Proton has no top-level bin folder, only files and the proton script, so never select that entry. It will keep appearing as long as any GE-Proton build sits in Lutris’s folder, whether ProtonUp-Qt put it there or you unpacked it by hand in the pin section.

Where Lutris and Heroic keep GE-Proton on Fedora

When a game misbehaves, you need to know which copy of GE-Proton ran it and which prefix it wrote to, before you change anything. These are the paths from our two test machines, with the Lutris RPM and the Heroic Flatpak:

Item	Lutris (Fedora RPM)	Heroic (Flatpak)
Default Wine version	GE-Proton (Latest)	Proton-CachyOS-latest on first launch
GE-Proton downloaded by the launcher	~/.local/share/Steam/compatibilitytools.d/	~/.var/app/com.heroicgameslauncher.hgl/config/heroic/tools/proton/
Pinned GE-Proton you add by hand	~/.local/share/lutris/runners/wine/	Wine Manager, GE-Proton tab
Installed by ProtonUp-Qt	~/.local/share/lutris/runners/wine/GE-Proton11-11-x86_64	~/.var/app/com.heroicgameslauncher.hgl/config/heroic/tools/proton/GE-Proton11-11-x86_64, plus the Lutris copy listed again
umu-launcher	~/.local/share/lutris/runtime/umu/	~/.var/app/com.heroicgameslauncher.hgl/config/heroic/tools/runtimes/umu/, fetched on first game launch
Steam Linux Runtime	~/.local/share/umu/steamrt4	Same directory, shared
Default prefixes	Whatever you set per game	~/Games/Heroic/Prefixes/
Folders it can read	Anything your user can	~/Games/Heroic, Documents, Desktop, ~/.steam, ~/.local/share/lutris, ~/.local/share/umu, /mnt, /media, /run/media, plus overrides

Two rows explain most of the disk use. Each launcher keeps its own GE-Proton at 1.6 GB per build, and builds pile up as Latest moves, so delete old directories from those two paths once no game is pinned to them. The runtime row is the cheap one, because one 703 MB copy serves both. If you also play through Steam, the Fedora 45 post-install checklist covers RPM Fusion and the rest of the desktop setup that games lean on.

All of this is assembly work that a gaming distro does for you. If you’d rather start from a preconfigured system, our Fedora 45 vs Bazzite comparison shows what you gain and give up. For a dedicated box under the TV, start with the mini PCs for Bazzite and SteamOS. For something you hold, the Steam Deck alternatives cover the Linux handhelds.