While checking why FSR 4 wasn’t kicking in on Pragmata, I noticed I already had proton-cachyos installed on my system from the proton-cachyos-slr package — but Steam wasn’t seeing it. That sent me down a small rabbit hole and I figured the result is worth its own post, since there’s a fair amount of confusion about whether this fork is needed at all on CachyOS.

This post covers what Proton-CachyOS actually changes on top of upstream Proton, how to set it up so Steam can use it, and when it’s worth pinning to a game.

What it is

Proton-CachyOS is a fork of Valve’s Proton Experimental maintained by the CachyOS developers. It tracks upstream closely and adds a curated set of patches drawn from Proton-GE, Proton-EM, and the CachyOS team’s own work. The fork is shipped via two pacman packages:

  • proton-cachyos — runs against host libraries.
  • proton-cachyos-slr — same Proton, packaged to run inside the Steam Linux Runtime container. SLR is how Valve packages official Proton, so this build behaves closer to Proton Experimental on systems where host libraries differ.

If you didn’t pick explicitly, you probably have proton-cachyos-slr already on CachyOS — it’s pulled in by the default gaming meta-package.

Caveat up front: this is not Valve’s Proton, and Valve does not support it. If you file a bug with a game running Proton-CachyOS, expect to be asked to reproduce on Proton Experimental first.

Configuring it

There are two pieces: making Steam see the build, then turning it on per game.

1. Make Steam see Proton-CachyOS

The pacman packages install to the system path /usr/share/steam/compatibilitytools.d/proton-cachyos-slr/, but Steam’s user install only reads ~/.local/share/Steam/compatibilitytools.d/. So even with the package installed, the entry may not appear in Properties → Compatibility.

Fix with a symlink:

ln -s /usr/share/steam/compatibilitytools.d/proton-cachyos-slr \
      ~/.local/share/Steam/compatibilitytools.d/proton-cachyos-slr
expose system-installed proton-cachyos to Steam

Then fully quit Steam (from the tray icon, not just the window) and start it again. The new entry appears as proton-cachyos-11.0-<date> (steam linux runtime) in the Compatibility dropdown.

2. Pin it to a specific game

Right-click the game in Steam → Properties → Compatibility → Force the use of a specific Steam Play compatibility tool → pick the proton-cachyos entry. Don’t set it as the system-wide default — pin per game on the titles that benefit, leave the rest on whatever Steam picks (usually Proton Experimental).

3. Configure per-game env vars

Most of what Proton-CachyOS adds is gated behind env vars. They go in Properties → General → Launch Options, before %command%:

PROTON_FSR4_UPGRADE=1 %command%
Steam launch options — single-var example

Multiple vars chain on one line:

PROTON_FSR4_UPGRADE=1 PROTON_DXVK_LOWLATENCY=1 %command%
Steam launch options — multiple vars

What it adds — the parts I actually care about

All of the following is pulled from the README and CHANGELOG on the cachyos_main branch.

Upscaler upgrades

This is the headline feature for AMD users. Proton-CachyOS can swap a game’s bundled upscaler DLLs at runtime, on a per-game basis, through env vars:

PROTON_FSR4_UPGRADE=1            # upgrade FSR 3.1 → FSR 4 (RDNA 4 cards)
PROTON_FSR4_RDNA3_UPGRADE=1      # enable FSR 4 on RDNA 3 cards (defaults to 4.0.0)
PROTON_FSR3_UPGRADE=1            # bump older FSR builds to current FSR 3.1
PROTON_DLSS_UPGRADE=1            # bump older DLSS to current DLSS version
PROTON_XESS_UPGRADE=1            # bump older XeSS to current XeSS version
per-game upscaler upgrades — set in Steam launch options

The downloader for the FSR 4 DLLs was broken for a while in earlier 11.0 builds; the 2026-05-06 release fixed it and added a fallback for changed DLL paths.

On my RX 9070 XT specifically, PROTON_FSR4_UPGRADE=1 is a no-op for Pragmata — the game’s own FidelityFX dispatcher already picks the FSR 4 path on RDNA 4. The env var earns its keep on games whose bundled FSR DLL doesn’t dispatch by hardware, and on RDNA 3 cards (with PROTON_FSR4_RDNA3_UPGRADE=1) which never get the upgrade otherwise.

OptiScaler integration (experimental)

This is the new piece in 11.0. Instead of dropping OptiScaler.dll into the game folder by hand (which is what my DLSS-on-AMD post walks through), Proton-CachyOS can inject OptiScaler from the Wine prefix:

PROTON_USE_OPTISCALER=1
PROTON_OPTISCALER_NAME=dxgi.dll   # or d3d12.dll, or dbghelp.dll (default: dxgi.dll)
native OptiScaler injection, no manual DLL drop

Config files end up at <prefix>/drive_c/windows/system32/umu/ alongside the DLLs. The CachyOS team calls this an early integration and asks you to verify the game still works without it before reporting bugs.

For Pragmata, my hand-installed OptiScaler still works and the OptiScaler wiki’s INI is more battle-tested, so I’m not in a rush to migrate. For games that don’t have a known-good OptiScaler config yet, the Proton-side path is more convenient.

Wayland and HDR

Proton-CachyOS imports Proton-EM’s winewayland.drv work. The HDR side is mostly plumbing for now — the CHANGELOG implements VK_COLORSPACE_HDR10_ST2084_EXT against version 3 of the wp_color_manager_v1 Wayland protocol, but the same note adds “no compositor supports it yet”. So the wiring is ahead of the compositor side; don’t expect HDR to just work end-to-end on KDE Plasma or GNOME today.

The one env var here:

PROTON_NO_WM_DECORATION=1   # fall back to Wine's own decorations
Steam launch options — Wayland decorations

Useful when KWin’s server-side decorations look wrong on a Wine window — Proton tells the compositor not to draw them and Wine draws its own instead. No effect on Xorg or under gamescope.

Latency and scheduling

NTSync is enabled by default in Proton 11 (CachyOS and Valve’s). The old PROTON_USE_NTSYNC env var has been removed. The kernel-side ntsync driver replaces Wine’s per-process synchronization primitives with kernel-backed ones — typically smaller CPU overhead and lower variance.

Env vars in this group:

PROTON_NO_NTSYNC=1          # disable NTSync if a title misbehaves
PROTON_DXVK_LOWLATENCY=1    # DXVK low-latency present mode (single-player)
PROTON_VKREFLEX=1           # NVIDIA Reflex Vulkan layer (NVIDIA only)
Steam launch options — latency / scheduling

PROTON_DXVK_LOWLATENCY=1 cuts input latency a frame or two in single-player titles; I avoid it in multiplayer (variable pacing can hurt aim consistency). PROTON_VKREFLEX=1 only does anything on NVIDIA hardware.

One related default that doesn’t need a launch option — wine-nvml (PROTON_NVIDIA_NVML=1) is on by default, so an in-game overlay can read GPU utilization without manual setup.

Smaller wins I keep finding useful

Env vars:

WINE_BLOCK_HOSTS="telemetry.example.com;updates.example.com"
                            # block Wine from reaching specific hosts.
                            # comma or semicolon separated, max 16 hosts,
                            # max 256 chars per host.

PROTON_D7VK_DDRAW=1         # DirectDraw via D7VK — older games that DXVK
                            # can't handle outright.
Steam launch options — host blocking + D7VK

WINE_BLOCK_HOSTS is useful for stopping a launcher’s telemetry without iptables rules.

One non-env-var item: DXVK-Sarek with experimental dyasync shader compilation is enabled by default in this fork — can speed up first-launch shader builds, but the README explicitly warns not to use the async branch with anti-cheat or multiplayer games.

When to use it

It’s worth switching to Proton-CachyOS for a given game when:

  • You’re on AMD and want the upscaler-upgrade env vars (FSR 4 on RDNA 3, DLSS/XeSS/FSR bumps). CachyOS is the build that fixes downloader regressions for these fastest.
  • You want OptiScaler without managing DLLs in the game folder yourself.
  • You want NTSync without manually overriding it per game (though Valve’s Proton 11 also defaults to NTSync now, so this is less of a differentiator than it was a year ago).
  • You want PROTON_DXVK_LOWLATENCY or WINE_BLOCK_HOSTS — these aren’t in upstream Proton.

When to stay on upstream Proton

  • The game uses kernel/userspace anti-cheat (EAC, BattlEye, Vanguard-like). Anti-cheat vendors only certify Valve’s official Proton builds; using a fork is not officially supported and some titles refuse to launch. Use Proton Experimental for those.
  • You’re filing a bug to Valve or the game developer. Reproduce on upstream Proton first — maintainers close issues opened against forks.
  • You hit a regression that doesn’t reproduce on upstream Proton. The fix path is faster on Valve’s tree.
  • You want maximum stability over feature velocity. Upstream Proton releases less often and more conservatively.

How I’m running it

Per-game, not as a system default. On games where I care about upscaling, I right-click → Properties → Compatibility → pick proton-cachyos-11.0-.... For everything else I let Steam choose.

The point: pin Proton-CachyOS on the titles that benefit from its env vars, leave the rest alone. You get the upside without losing access to anti-cheat games or Valve’s bug-reporting pipeline.

References