TL;DR
Stock Fedora KDE already does most of this. Fedora 44 ships Plasma 6.6, and Plasma has had real VRR and basic HDR under Wayland for a while now, no extra login session, no third-party spin required. Check you are on Wayland, flip the two toggles in System Settings, and only reach for gamescope when you want a per-game frame cap or an isolated compositor around Steam. Here is the fast path:
$ echo $XDG_SESSION_TYPE
wayland
$ kscreen-doctor -o | grep -E 'Vrr|HDR'
Vrr: capable
HDR: capable
$ sudo dnf install gamescopeIf the session line says x11 instead of wayland, stop here and switch first (see Step 1). Neither VRR nor HDR exist on Plasma's X11 session.
What Plasma 6.6 already gives you
For years the honest answer to "can I game on Linux with a decent monitor" was "sort of, with a workaround." That is not really true anymore on Fedora KDE. Plasma's Wayland session picked up basic HDR support back in Plasma 6.0 (the work came out of an HDR hackfest Red Hat organized in 2023), and KWin's variable refresh rate handling predates Plasma 6 entirely. Fedora 43 added an HDR calibration wizard to System Settings, and Plasma 6.6, which is what Fedora 44 ships, made HDR behave more consistently between fullscreen games and plain windowed apps instead of only working properly in one or the other.
None of that is marketing. Fedora itself is betting on it: in January 2026 FESCo approved moving the Fedora Games Lab spin from Xfce to KDE Plasma 6.6 specifically to show off the Wayland gaming stack, citing the work Valve and other contributors have put into it. If Fedora's own gaming showcase spin is standing on Plasma now, "vanilla Fedora KDE" is a reasonable place to start, not a compromise before you install something fancier.
So the real question is not "how do I bolt gaming features onto Fedora KDE." It is "which of these are already on, which do I need to turn on, and which one (gamescope) is a separate tool that layers on top." That is the order this post follows.
Step 1: confirm you are actually on Wayland
Everything below is Wayland-only. If you installed Fedora a while back and never switched, or you are on a hand-me-down config, check first.
$ echo $XDG_SESSION_TYPEwaylandIf you get x11 back, log out, and on the SDDM login screen click the small gear or session icon near the password field, then pick "Plasma (Wayland)" before you log back in. There is no VRR, no HDR, and no gamescope session on Plasma's X11 session; KWin never implemented any of it there, and at this point it will not.
Step 2: turn on VRR properly
Variable refresh rate stops your display's refresh from being locked to a fixed number, so a game running at 87fps does not get torn or stuttered trying to fit into a 60Hz or 144Hz grid. KWin has had a VRR policy since well before Plasma 6; what changed more recently is reliability, not the feature's existence.
Check what KWin thinks your output can do:
$ kscreen-doctor -oOutput: 1 DP-1
Enabled: true
...
Vrr: capable
HDR: capable
...The real output is longer (modes, geometry, scale, rotation); I trimmed it to the two lines that matter here. If your monitor is advertised as FreeSync or G-Sync Compatible and this still says Vrr: incapable, do not assume the feature is broken on Linux specifically: that false negative is a documented, reported issue (both an openSUSE forum thread and a Manjaro forum thread describe the exact same "incapable even though it clearly supports it" symptom), and it is usually a cable or a monitor-side setting, covered in "If this fails" below.
To actually enable it: System Settings → Display and Monitor → click your monitor → look for the Variable Refresh Rate (sometimes labeled Adaptive Sync) dropdown with Automatic, Never, and Always options. Automatic is the sane default: KWin enables VRR only for fullscreen content, which is where it actually helps and where driver bugs are least likely to show up. There have been upstream discussions about disabling adaptive sync by default because of displays blanking when some drivers toggle it, so if you hit flicker or a brief blank on scene changes, Automatic (not Always) is where to start, and dropping to Never is a legitimate fallback, not a failure on your part.
Step 3: HDR, and why "basic" is the accurate word for it
HDR on Linux in 2026 is real but young. The developer who led the KWin HDR work described the initial implementation as "quite basic at first," and that is still the right expectation to carry in. It works. It is not yet as automatically correct across every app as HDR on a console or on Windows.
Turn it on: System Settings → Display and Monitor → your monitor → HDR toggle. On Fedora 43 and newer you will also see a calibration wizard here; run it once per monitor. It walks you through setting the SDR brightness level inside the HDR colorspace so normal desktop content does not look washed out while HDR content pops.
What it will not magically fix: apps and games that do not know HDR exists will render correctly but flatter than they could. That is expected, not a bug in your setup. Toggle HDR off when you are not gaming if you find desktop colors look off; there is no shame in treating it as a mode you switch into, the way plenty of Windows users already do.
Step 4: if you run NVIDIA, check your driver series before blaming Plasma
A huge share of "Wayland plus NVIDIA is still broken" complaints you will find online are about driver versions that are simply old at this point. Explicit sync, the protocol that lets KWin and apps hand off frames cleanly without the flicker and corruption that defined NVIDIA-on-Wayland for years, needs the 555 series or newer. If you are still seeing that kind of glitching, this is step zero, before you touch VRR or HDR settings at all.
$ cat /proc/driver/nvidia/versionNVIDIA UNIX Open Kernel Module for x86_64 (version number here) Release BuildOr, if you have the full driver stack with nvidia-smi working:
$ nvidia-smi --query-gpu=driver_version --format=csv,noheader580.65.06(Your number will differ; what matters is that it is 555 or higher.) One more wrinkle worth knowing about: starting with the 560 series, NVIDIA's own default moved to the open-source kernel module, which only supports Turing-generation cards (RTX 20-series) and newer. If you are on a Maxwell, Pascal, or Volta card, you still want the proprietary kernel module, not the open one; RPM Fusion's packages for Fedora 44 support both, so check which one `akmod-nvidia` pulled in if you are unsure.
Step 5: where gamescope actually fits in
Gamescope is Valve's own micro-compositor, the same piece of software that runs the Steam Deck's gaming mode. On the Deck it is the whole session. On a regular Fedora KDE desktop it is something narrower and, honestly, more useful for most people: a nested compositor you launch around a specific game or around Steam itself, to get a hard FPS cap, forced VRR, or HDR passthrough for that one process without changing anything about your actual desktop session.
It has shipped in Fedora's own repositories (no RPM Fusion needed) since Fedora 41, and that has carried forward:
$ sudo dnf install gamescopeInstalling:
gamescope x86_64 3.16.x-1.fc44 fedora ...
...
Complete!If your mirror has not caught up and dnf comes back empty, run dnf search gamescope first before assuming it is missing; as a last resort there are community COPR repos that track gamescope's upstream git directly, which is also how you get newer point releases before Fedora's own package updates.
To use it, wrap Steam (or a single game's launch command) in it instead of running it directly:
$ gamescope -W 2560 -H 1440 -r 144 --hdr-enabled --rt -- steam(gamescope's exact startup log varies by version and build; expect a short
burst of its own [Info] lines as it sets up the nested compositor and
negotiates the output, then Steam's own window opens as normal, now
running inside gamescope's frame)Drop --hdr-enabled if you have not turned HDR on at the desktop level first; gamescope cannot grant a capability your monitor and KWin have not already negotiated. One thing worth flagging honestly: there is a report, in a KDE forum thread and in gamescope's own GitHub issue tracker, that after Plasma 6.7, --hdr-enabled stops exposing HDR to the game at all. Fedora 45 is due around October 20, 2026, and ships Plasma 6.7, so if you upgrade on day one and HDR inside gamescope stops working, you are not imagining it; I have not been able to verify a fix landed yet, so treat it as a known open issue rather than something you misconfigured.
One thing gamescope is not, on stock Fedora KDE: a session you pick on the SDDM login screen the way you would on a Deck or on Bazzite. That kind of "gamescope session" entry exists only through an unofficial COPR built for Fedora's Atomic desktops, installed via rpm-ostree, with its own maintainer and its own bug tracker, separate from Fedora proper. If a guide tells you to just select a gamescope session at login on a normal Fedora KDE workstation install, it is describing that add-on, not something that ships by default.
If this fails
Common failure points
kscreen-doctor says "Vrr: incapable" on a monitor you know supports FreeSync/G-Sync. This is a known, reported false negative, not necessarily your setup being broken. Check the monitor's own on-screen menu first: VRR has to be enabled on the display side too, and it is off by default on a lot of monitors out of the box. Next, check the cable: VRR signaling is inconsistent over some DisplayPort-to-HDMI or long passive HDMI cables even when the base image works fine.
HDR makes the whole desktop look grey and washed out instead of better. Run the calibration wizard (System Settings → Display and Monitor → HDR) if you have not; it sets your SDR reference brightness inside the HDR colorspace, and skipping it is the single most common cause of "HDR looks worse" reports. If a specific app still looks wrong after calibration, that app likely has no HDR awareness yet and is being tone-mapped by KWin as a best effort; toggling HDR off while using that app is a reasonable workaround, not a failure.
gamescope exits instantly or drops to a black screen instead of showing Steam. On NVIDIA, this is almost always an old driver running a nested Wayland compositor it was never tested against. Confirm your driver series with the commands in Step 4 before filing a bug anywhere; updating to a current RPM Fusion build fixes the large majority of these reports.
None of this needs a special spin, a Bazzite-style image, or a from-scratch tiling setup. Stock Fedora KDE, kept current, already carries the Wayland-era gaming stack that used to be the differentiator for other distros. Gamescope is a sharp tool to add on top for specific games, not a replacement for any of the above. If you have not seen what current Fedora KDE looks like day to day outside of gaming, our full review of Fedora KDE Plasma Edition covers that ground. And if NVIDIA plus Wayland is still fighting you after the driver check above, the deeper troubleshooting guide is here: KDE Plasma on Wayland with NVIDIA, the definitive troubleshooting guide.