KDE Plasma on Wayland with NVIDIA in 2026: What Still Breaks and How to Fix It

$ echo $XDG_SESSION_TYPE
wayland
$ plasmashell --version
plasmashell 6.7.4
$ nvidia-smi --query-gpu=driver_version --format=csv,noheader
595.91.07
$ cat /sys/module/nvidia_drm/parameters/modeset
Y

Why this used to be a nightmare, and mostly isn't anymore

Wayland compositors like KWin expect the GPU driver and every client to hand off frame buffers with explicit synchronization: a fence that says a frame is actually done rendering, not an implicit signal the compositor has to guess about. NVIDIA's proprietary driver used a different buffer submission model for years, and the gap between the two showed up as the exact symptoms that filled every KDE forum thread for a long stretch: flickering XWayland windows, panels losing focus at random, full black screens after the display went to sleep. AMD and Intel's open source drivers supported explicit sync earlier, which is why "just switch to AMD" became the default advice for anyone who wanted a Wayland desktop that behaved.

That changed with KWin 6.1 adding the explicit sync protocol on the compositor side and NVIDIA's driver 555.58 implementing it on theirs. By Plasma 6.7.4 with a current driver, the flicker and focus loss that used to be the default experience is gone for most people. We covered the bigger picture, and where NVIDIA support stands as a whole, in our review of Fedora's KDE Plasma Edition. What is left in 2026 is not "does the desktop work," it is a short, specific list of edge cases, and that list is the rest of this guide.

Step 1: confirm what you're actually running

Before chasing any of the fixes below, confirm you are actually in a Wayland session (not an X11 fallback you did not notice) and note your exact Plasma, driver, and XWayland versions, because every fix past this point is version specific:

$ echo $XDG_SESSION_TYPE
wayland
$ plasmashell --version
plasmashell 6.7.4
$ nvidia-smi --query-gpu=driver_version --format=csv,noheader
595.91.07
$ rpm -q xorg-x11-server-Xwayland
xorg-x11-server-Xwayland-24.1.13-1.fc44.x86_64

The explicit sync path needs all three of Plasma 6.1 or newer, driver 555.58 or newer, and Xwayland 24.1 or newer to actually engage. If any one of the three is older, XWayland apps silently fall back to the old behavior and you are debugging a problem that a version bump would have solved on its own.

Step 2: get a current driver from RPM Fusion, not a random script

Fedora does not ship the proprietary NVIDIA driver, RPM Fusion does, and it is the version that actually carries the explicit sync fixes and current kernel compatibility, not whatever a generic "install NVIDIA on Linux" guide from a few years back tells you to run:

$ sudo dnf install -y https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
Complete!
$ sudo dnf install -y akmod-nvidia
Complete!
$ modinfo -k "$(uname -r)" -F version nvidia
595.91.07
$ sudo reboot

akmod rebuilds the kernel module against whatever kernel Fedora ships you next, which is the entire point: it survives kernel updates instead of breaking on the next dnf upgrade the way a manual .run installer does. The build kicks off automatically in the background as soon as akmod-nvidia installs, give it five to ten minutes before you check, and modinfo will come back empty until it finishes. If it is still empty after a real wait, force it explicitly with sudo akmods --force --kernels "$(uname -r)" and check again before rebooting.

Step 3: make sure DRM kernel modesetting is actually on

This is the step people skip because it usually just works, and the one time it does not, everything above looks fine while Plasma still starts in a degraded fallback that is hard to trace back to this one flag:

$ cat /sys/module/nvidia_drm/parameters/modeset
Y

If that comes back N, set it explicitly and reboot:

$ sudo grubby --update-kernel=ALL --args="nvidia-drm.modeset=1"
$ sudo reboot
$ cat /sys/module/nvidia_drm/parameters/modeset
Y

RPM Fusion's package has shipped with modeset on by default for a while now, so a clean, fresh install rarely needs this. Where it bites people is a system upgraded across a couple of Fedora releases, or one where an older manual NVIDIA install left conflicting modprobe configuration behind in /etc/modprobe.d.

Step 4: variable refresh rate, and the one thing that's still flaky

Turn it on per output in System Settings, Display and Monitor, Adaptive Sync, set to Automatic. Before you do, confirm the monitor is actually reporting VRR capability at the kernel and driver level, since no Plasma setting can fix a display that isn't offering it:

$ kscreen-doctor -o
Output: 1 HDMI-A-1 enabled connected priority 1
  Modes: ...
  Vrr: capable

If that line reads incapable instead, the monitor, the cable, or the port is not giving you VRR at the display protocol level. Check the monitor's own on-screen menu for its adaptive sync toggle, and confirm the cable is actually DisplayPort or HDMI 2.1, not an older HDMI 1.4 run that caps out below what VRR needs.

The specific bug still open on some panels as of this writing: with VRR enabled, letting the monitor go to sleep and waking it back up can leave it reporting no signal until you disable and re-enable the output, or reboot. It is tracked as a driver issue, not a KWin one, and it does not hit every monitor, it shows up mostly on specific G-Sync Compatible panels. If you hit it, the two workarounds that actually help are turning VRR off for that one output, or setting the screen to never blank instead of letting it go through a DPMS sleep cycle, until NVIDIA ships a fix for your panel.

Step 5: HDR, the part that isn't actually fixed yet

Be straightforward about this one: HDR support in KDE Plasma on NVIDIA is the newest piece of this stack and the least settled. On some monitor and driver combinations on the current 595.x branch, toggling HDR on in System Settings throws an error dialog and reverts on its own, with the message The driver rejected the output configuration.

That is not a KDE-specific bug, the same message shows up on NVIDIA's own developer forums against the same driver branch on other Wayland compositors too, and there is no reliable universal fix as of this writing. If you hit it, do not burn an evening on it: leave HDR off, check the NVIDIA Linux driver README changelog before your next driver update to see whether it is listed as resolved, and if HDR genuinely matters for what the machine is for, that is a legitimate reason to weigh an AMD card for that specific box, not a sign you configured something wrong.

Step 6: XWayland apps that still flicker

If you have confirmed Plasma 6.1 or newer, driver 555.58 or newer, and Xwayland 24.1 or newer from step 1, and an XWayland app still flickers, the fastest thing to try is a clean session reload: log out and back into the Wayland session rather than guessing at a compositor restart command, since that reliably reinitializes XWayland from scratch. If it comes back after a clean login, it is worth filing against the specific application rather than the desktop, most of what is left at this point is app-side rendering paths, not the compositor or driver.

Wrap up

In 2026, KDE Plasma on Wayland with an NVIDIA GPU is not the minefield it was a couple of years ago. The default path, a current driver from RPM Fusion, modesetting on, a recent Plasma release, works out of the box for most people. What is left, VRR sleep and wake behavior, HDR, is a short list, and every driver release tends to make it shorter rather than longer. If you want the wider picture of where Fedora's KDE Plasma Edition stands as a whole in 2026, we covered that in the full review.