The screen tears right when you need it most
You boot into Fedora, launch a fast-scrolling terminal or a competitive game, and the display splits horizontally. The top half shows frame 42. The bottom half shows frame 41. You know your monitor supports FreeSync or G-Sync Compatible. You know Fedora is supposed to handle modern displays. The tearing persists because the kernel driver, the desktop compositor, and the display panel are not negotiating the same refresh language.
What VRR actually does under the hood
Variable Refresh Rate aligns the GPU frame delivery clock with the monitor scan clock. Without VRR, the GPU pushes frames at a fixed interval while the monitor refreshes at a fixed interval. When those two clocks drift, the monitor draws part of one frame and part of the next. You see tearing. VRR tells the panel to wait for the GPU signal before starting a new scan. The monitor refreshes exactly when a new frame arrives.
Think of it like a delivery service. Fixed refresh is a truck that leaves the warehouse every hour regardless of whether the packages are ready. Variable refresh is a truck that leaves only when the packages are loaded. Fedora enables this automatically when the kernel DRM subsystem reports support and the desktop environment requests it. The catch is that the kernel, the driver, the compositor, and the monitor firmware must all agree.
Check your hardware and driver baseline
Start by confirming which GPU driver is actually loaded. The kernel loads different modules depending on the silicon. Run this to see what the system recognizes:
lsmod | grep -E "amdgpu|nvidia"
# WHY: lsmod lists currently loaded kernel modules.
# WHY: The grep filter isolates the graphics driver names.
# WHY: amdgpu indicates AMD open-source driver support.
# WHY: nvidia indicates the proprietary stack is active.
# WHY: If neither appears, the kernel did not detect the GPU.
Convention aside: Fedora ships with the amdgpu driver built into the kernel. It loads automatically for supported AMD silicon. NVIDIA requires the proprietary akmod-nvidia package from RPM Fusion. If you are on a fresh install and nvidia is missing, install it before touching display settings. Manual driver edits drift. Trust the package manager.
Run dnf upgrade --refresh before proceeding. The command forces the package manager to check for updated driver packages and kernel modules. Stale driver versions often lack the latest EDID parsing patches required for VRR handshakes.
Enable VRR on AMD GPUs
AMD GPUs handle VRR through the kernel and the DRM subsystem. The driver exposes the capability to the display server. GNOME on Wayland reads that capability and enables it without extra configuration. Open GNOME Settings and navigate to Displays. Click the refresh rate dropdown for your monitor. Select the highest available option. Wayland will automatically negotiate the variable rate with the panel.
You do not need to edit Xorg configuration files. You do not need to toggle experimental flags. The compositor handles the handshake. If you are stuck on X11 for legacy reasons, the xrandr tool exposes the variable mode. Run this to list available modes:
xrandr --query --verbose
# WHY: --query dumps the current CRTC and output state.
# WHY: --verbose appends detailed flags including VRR support markers.
# WHY: Look for "variable refresh" or "adaptive sync" under your active output.
# WHY: The output confirms whether the X server recognizes the capability.
Select the mode with xrandr --output <your_port> --mode <resolution> --rate <highest_hz>. The X server will switch to the variable rate if the driver advertises it. Reboot before you debug. Half the time the compositor cache holds an old mode list.
Enable VRR on NVIDIA GPUs
The proprietary NVIDIA driver disables Adaptive Sync by default on many configurations. The driver prioritizes stability over variable refresh. You must explicitly opt in through an Xorg configuration snippet. Create a drop-in file in the system configuration directory:
sudo nano /etc/X11/xorg.conf.d/20-nvidia.conf
# WHY: /etc/X11/xorg.conf.d/ is the user-modified configuration directory.
# WHY: Files in /usr/lib/X11/ ship with the package and get overwritten on updates.
# WHY: Always edit /etc/ to preserve your changes across driver upgrades.
# WHY: The 20- prefix ensures the file loads after default vendor configs.
Add the following section to the file:
Section "Device"
Identifier "NVIDIA Card"
Driver "nvidia"
Option "AllowEmptyInitialConfiguration" "true"
Option "AllowGpuReset" "1"
Option "UseDisplayDevice" "CRT-0"
Option "AdaptiveSync" "true"
EndSection
The AdaptiveSync flag tells the NVIDIA kernel module to expose the VRR capability to Xorg. The AllowEmptyInitialConfiguration flag prevents the X server from crashing if it detects a disconnected port during startup. Save the file and restart the display manager. Run sudo systemctl restart gdm for GNOME or sudo systemctl restart sddm for KDE. A full reboot works if the service restart hangs.
Convention aside: systemctl status gdm shows recent log lines and the current state in one view. Always check status before restart. If the service fails to start, the X server likely rejected the configuration syntax. Check /var/log/Xorg.0.log for EE errors.
Verify the refresh rate is actually variable
Confirmation requires checking the active mode flags. Run this command to see what the display server actually negotiated:
xrandr --query --verbose | grep -i "variable\|adaptive"
# WHY: grep filters the verbose output for VRR keywords.
# WHY: A match confirms the compositor and driver agreed on a variable rate.
# WHY: No output means the monitor is locked to a fixed refresh rate.
# WHY: The command works on X11 sessions and reports the active CRTC state.
If you are on Wayland, xrandr reports the X11 fallback state. Use gnome-shell --version to confirm your session type. Wayland sessions do not expose xrandr output directly. Instead, open the GNOME Tweaks tool or run gsettings get org.gnome.mutter experimental-features. If the output includes vrr, the compositor is actively managing the refresh rate.
Run journalctl -xeu gdm after a reboot to catch any compositor warnings. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Read the actual error before guessing.
Common pitfalls and exact error messages
The most common failure is a monitor firmware setting. Many panels ship with FreeSync or Adaptive Sync disabled in the on-screen display menu. Open the monitor OSD and enable the feature. The second failure is bandwidth. HDMI 2.0 caps at 4K 60Hz. If you are pushing 4K 120Hz over HDMI 2.0, the link drops to a fixed rate or disables VRR entirely. Switch to DisplayPort 1.4 or HDMI 2.1.
The third failure is a conflicting GNOME setting. Some users force a fixed refresh rate in gsettings to fix scaling issues. Run gsettings reset org.gnome.mutter experimental-features to clear manual overrides. You will occasionally see this exact error in the journal when the driver refuses to enable VRR:
(EE) NVIDIA(0): Failed to enable Adaptive Sync on output DP-0
The error means the monitor did not advertise FreeSync compatibility over the active cable, or the driver version lacks the necessary EDID parsing patch. Update the akmod-nvidia package and reseat the display cable. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A botched config edit can leave you unable to start the display manager. Run this from a backup VM first if you can.
Which path matches your setup
Use AMD open-source drivers when you want plug-and-play VRR with zero configuration files. Use NVIDIA proprietary drivers when you need CUDA compute or specific game compatibility. Use Wayland when you want native compositor-level VRR handling without Xorg workarounds. Use X11 when you rely on legacy window managers or remote desktop protocols that break under Wayland. Stay on the default GNOME display settings if your monitor advertises the correct EDID capabilities.