When the official build falls short
You install a new Windows title on Fedora. Steam finishes downloading. You click play. The game crashes to desktop with a Vulkan initialization failure, or the anti-cheat module refuses to start. You check the community database and see a clear recommendation for a specific community fork. You open the compatibility tool dropdown in Steam, but the option is missing. The official Valve build is the only thing listed.
This happens because Steam does not ship the community fork by default. Valve maintains a curated compatibility layer that prioritizes stability across thousands of titles. The community fork tracks the same base code but ships newer graphics translation layers, experimental patches, and game-specific workarounds. Steam only shows compatibility tools that live in a specific user directory. If the folder is not there, the menu stays empty. You are not missing a package manager command. You are missing a directory placement.
How Steam loads compatibility tools
Steam treats compatibility tools as self-contained runtime environments. Each tool lives in its own directory inside compatibilitytools.d. The directory name becomes the tool name in the Steam UI. Inside that directory, Steam expects a compatibilitytool.vdf manifest file that defines the Wine version, the DXVK and VKD3D builds, and the patch set. When you launch a game, Steam reads the manifest, mounts the tool, and injects it into the game's Wine prefix.
Valve updates their official Proton builds on a conservative schedule. They test against a broad matrix of hardware and titles before pushing an update. The community fork, maintained by GloriousEggroll, updates weekly. It pulls the latest upstream Wine commits, bumps DXVK and VKD3D to bleeding-edge releases, and backports fixes for games that broke in the official build. The trade-off is stability. The official build rarely breaks working games. The community fork occasionally introduces regressions while chasing new patches.
Steam on Fedora runs as a native client by default. The native client stores user data in ~/.local/share/Steam/. If you installed Steam via Flatpak, the sandbox isolates your files in ~/.var/app/com.valvesoftware.Steam/.steam/steam/. Know which client you are running before you move files. Placing the tool in the wrong directory leaves the dropdown empty and wastes time.
Placing GE-Proton on your system
You need to download the archive, extract it to the correct directory, and let Steam read the manifest. The process takes three commands. Run them in order.
Here is how to create the directory if it does not exist yet and download the latest release.
# Create the compatibility tools directory for the native Steam client
mkdir -p ~/.local/share/Steam/compatibilitytools.d
# Fetch the latest GE-Proton archive directly from GitHub releases
wget -q https://github.com/GloriousEggroll/proton-ge-custom/releases/latest/download/GE-Proton*.tar.gz -O /tmp/ge.tar.gz
# Extract the archive into the tools directory without creating nested folders
tar -xzf /tmp/ge.tar.gz -C ~/.local/share/Steam/compatibilitytools.d
Restart Steam completely. Close it from the system tray, then relaunch. Open your game properties, navigate to the compatibility section, and check the box that forces a specific tool. The dropdown will now list the GE-Proton version you just extracted. Select it and save.
If you use the Flatpak version of Steam, the path changes. The Flatpak sandbox requires you to place the tool inside the Flatpak's data directory. Run this instead.
# Create the tools directory inside the Flatpak sandbox
mkdir -p ~/.var/app/com.valvesoftware.Steam/.steam/steam/compatibilitytools.d
# Extract the archive into the Flatpak-specific path
tar -xzf /tmp/ge.tar.gz -C ~/.var/app/com.valvesoftware.Steam/.steam/steam/compatibilitytools.d
Steam reads the directory on startup. A full restart forces the UI to refresh its tool list. Do not rely on the "Refresh" button in the library. Close the client entirely.
Verify the fork is active
Steam does not always update the UI immediately after a selection change. The game might still launch with the official build if the prefix is cached or if the manifest failed to parse. Check the runtime log to confirm the correct tool loaded.
Here is how to locate the log file for your game and verify the compatibility layer.
# Replace 123456 with your actual Steam App ID
LOG_FILE=~/.local/share/Steam/logs/steam-app-123456.log
# Print the first twenty lines to check the tool header
head -n 20 "$LOG_FILE"
Look for a line that reads GE-Proton9-25 or similar in the header. If you see Proton 8.0 or Proton Experimental, the wrong tool loaded. Clear the cache by deleting the compatibilitytools.d temporary extraction folder inside the game's prefix, or simply delete the game's pfx folder and let Steam rebuild it. The rebuild takes a few seconds and forces the new tool to initialize cleanly.
You can also verify the active DXVK and VKD3D versions from the terminal while the game is running. This confirms the community patches are actually injected.
# Find the running game process by name
PID=$(pgrep -f "game.exe")
# Read the environment variables Steam injected for that process
cat /proc/$PID/environ | tr '\0' '\n' | grep -i dxvk
The output should show DXVK_VERSION=2.4 or higher, depending on the GE release. If it shows an older version, the manifest is pointing to a cached build. Delete the old GE folder and extract the fresh archive again.
Run the log check before you blame your GPU drivers. Half the time the issue is a stale prefix, not a broken installation.
Common pitfalls and log symptoms
The most frequent failure is path confusion. Native Steam and Flatpak Steam do not share directories. Placing the tool in ~/.local/share/Steam/ while running the Flatpak client leaves the dropdown empty. Check your installation method with rpm -q steam or flatpak list | grep steam. Match the path to the client.
Another common issue is leaving multiple GE versions in the directory. Steam lists every folder it finds. Keeping GE-Proton8-30, GE-Proton9-10, and GE-Proton9-25 clutters the menu and increases the chance of selecting an outdated build. Remove old versions manually.
# List all compatibility tools currently installed
ls -1 ~/.local/share/Steam/compatibilitytools.d/
# Remove a specific old version to keep the menu clean
rm -rf ~/.local/share/Steam/compatibilitytools.d/GE-Proton8-30
Some games refuse to run with GE-Proton because the community patches conflict with proprietary anti-cheat modules. You will see a log line like Failed to initialize anti-cheat module or dxgi: CreateDXGIFactory1 failed. This is not a Fedora issue. It is a Windows compatibility layer limitation. Switch back to the official Proton build or check the game's documentation for supported launchers.
SELinux does not block Steam from reading user directories. If you see permission denied errors in the log, check the ownership of the extracted files. The archive should extract with your user as the owner. If you ran the extraction with sudo, the files belong to root and Steam cannot read them. Fix the ownership immediately.
# Restore correct ownership if you accidentally used sudo during extraction
sudo chown -R $USER:$USER ~/.local/share/Steam/compatibilitytools.d/
Check the log header before you reinstall drivers. The error is almost always a path mismatch or a stale prefix.
Choose the right compatibility layer
Use the official Valve Proton build when you want maximum stability across a large library and do not need bleeding-edge graphics patches. Use GE-Proton when a specific title requires newer DXVK/VKD3D versions, needs a community backport, or fails on the official build due to a known regression. Use Lutris or ProtonUp-Qt when you manage multiple non-Steam launchers and want a single GUI to download and switch compatibility tools across different platforms. Stay on the native Steam client if you want direct filesystem access and predictable log paths.
Pick the tool that matches the game's requirements. Do not force GE-Proton on titles that already run perfectly on the official build.