26/08/25 - Monitor Flickering in Hyprland¶

Hyprland Monitor Flicker Issue¶

So I thought I was going to get up today and write out a plan for the MkDocs website, instead I booted my PC and the monitor in DP-1 was going crazy. It booted into GDM fine, no display issues. The issue was after logging in, where I transition from GDM to Hyprland, so I figured the issue is inside that scope.

This has been something my monitor has done for a while since moving from GNOME to Hyprland, but rebooting the machine always fixes the issue, and it's a lot easier to reboot the machine then figure out why something doesn't work.

Let's get this fixed properly, today.

I am currently using end4 dotfiles, with quickshell, and there are lots of quickshell plugins, they could be a part of the issue as quickshell plugins have caused me other issues in the past with CPU usage and the quickshell process getting stuck in a restart loop.

The best idea is to make my own hyprland configuration from scratch but for now I just want to figure out why this monitor issue happens.

It only happens on hyprland and only with my current configuration. So it's not a hardware issue, it's almost certainly hyprland related.

What ChatGPT said:

Problem¶

On boot into Hyprland (via GDM), my primary monitor (DP-1, 144 Hz) would sometimes flicker rapidly, turning black, then recovering, repeating indefinitely.
This issue only appeared in Hyprland (not in GNOME, XFCE or other DEs), and only on cold logins—not after reboots.

My Config¶

monitors monitor=DP-1,2560x1440@144,0x0,1 
monitor=DP-2,2560x1440@60,2560x0,1 
monitor=DP-2,transform,3

Investigation¶

Verified that the issue was specific to Hyprland, not the monitor hardware.
Checked journalctl -k -b for GPU/DRM messages. Confirmed I am running on NVIDIA proprietary driver (580.76.05) and wlroots-based compositor (Hyprland).
Observed that Hyprland was re-applying monitor modes in a loop, which is consistent with atomic commit failures on wlroots.
Suspected VRR (Variable Refresh Rate) and mixed refresh rates as the trigger:
DP-1: 2560×1440 @ 144 Hz (with VRR).
DP-2: 2560×1440 @ 60 Hz, rotated.

This combination is known to cause issues on wlroots + NVIDIA.

Actions Taken¶

Edited my Hyprland config and dropped DP-1 to 60 Hz with VRR enabled:

monitor=DP-1,2560x1440@60,0x0,1,vrr,1

Result: flicker stopped immediately.

From this, confirmed the bug was due to VRR + 144 Hz + mixed refresh on NVIDIA.
Permanent fix:

Keep DP-1 at 144 Hz but disable VRR explicitly:

monitor=DP-1,2560x1440@144,0x0,1,vrr,0
monitor=DP-2,2560x1440@60,2560x0,1,transform,3,vrr,0

Ensure only one config line per monitor (combine transform + mode) to avoid double atomic commits.
Add NVIDIA-specific stabilizers in env.conf:
```
env = WLR_NO_HARDWARE_CURSORS,1
```

Outcome¶

With VRR disabled on DP-1 (and DP-2), the system is stable at 144 Hz with no flicker.
Confirmed across multiple logins: issue is gone.

Lessons Learned¶

VRR + NVIDIA + wlroots is fragile, especially with mixed refresh + rotation.
Always test minimal configs (dbus-run-session hyprland --config /tmp/min.hypr) to isolate whether the bug is in Hyprland, plugins, or hardware.
For reproducibility:
If monitor flicker appears, first step is to disable VRR on the affected monitor.
Then reintroduce features (rotation, mixed refresh, plugins) one at a time.

With all that said, I'm not convinced it wasn't just the refresh rate. That was the last thing I changed in ~/.config/hypr/hyprland.conf, and the only change that made an immediate difference.

Hyprctl monitors says it is a 144hz monitor so I don't understand why changing it to 60hz in my hyprconfig fixed it but it did.

Resolved.

To Do¶

Investigate if VRR can be re-enabled safely on the 144 Hz monitor once NVIDIA/Hyprland improve support.
Add notes about this bug to a dedicated NVIDIA quirks documentation page.
Keep testing with hyprctl logs -f when adjusting monitor configs to capture atomic commit failures in real time.