VRR broken in Hyprland

[Tractix]

Hyprland Version

System/Version info

Hyprland, built from branch HEAD at commit 03ebbe18ed8517ee22591eac82cd54322f42cb7d  (props: bump ver to 0.34.0).
Date: Mon Jan 1 12:03:15 2024
Tag: v0.34.0

flags: (if any)

Bug or Regression?

Bug

Description

I've noticed VRR doesn't seem to be working properly.

In Quake II RTX if I lower the graphical settings and get around 80ish fps, the refresh rate will constantly stay at 165hz on my monitor (checked using monitor's OSD) which it shouldn't. The monitor's refresh rate should match the game's fps.
If I up the graphical settings and get to 40 - 50fps (still within VRR range), the monitor's refresh rate will go wild switching quickly between 165hz to either 50/60 or 70 hz and will keep switching between those refresh rates and the screen backlight will sometimes flash.

On both Baldur's Gate 3 and FFXIV I get around 120 - 150 fps but the refresh rate will stay at 165hz all the time and not syncing up at all.

My VRR range is between 20hz and 165hz (check rtings link below). 165hz is my max refresh rate.

I've used VRR before on my older GPU (2060 Super) and when in VRR mode, the refresh rate always synced up with the game's fps staying similar both on Windows and X11 meaning it's not a monitor or cable issue.

I am on Arch Linux, I use 7900XT gpu and I have this monitor https://www.rtings.com/monitor/reviews/msi/optix-mag274qrf-qd hooked up via display port. This happens when VRR is set to 2 or 1 in hyprland config. In-game fps was checked using both mangohud and in-game fps counter. Vsync was turned off in-game. I also only use 1 monitor (the monitor listed above).

I've used env --unset=SDL_VIDEODRIVER %command% to launch BG3. I also use these enviromental variables if it matters:

EDITOR=/usr/bin/nano
DXVK_FRAME_RATE=160

QT_QPA_PLATFORM="wayland;xcb"
QT_QPA_PLATFORMTHEME=qt6ct
KITTY_ENABLE_WAYLAND=1
CLUTTER_BACKEND=wayland
GDK_BACKEND=wayland,x11
XDG_SESSION_TYPE=wayland
EGL_PLATFORM=wayland
#SDL_VIDEODRIVER=wayland
SDL_VIDEODRIVER="wayland,x11"

XDG_CURRENT_DESKTOP=Hyprland
XDG_SESSION_TYPE=wayland
XDG_SESSION_DESKTOP=Hyprland

QT_AUTO_SCREEN_SCALE_FACTOR=1
QT_WAYLAND_DISABLE_WINDOWDECORATION=1

How to reproduce

Run Quake II RTX, set settings graphical settings to high or low and notice how the in-game fps won't match the refresh rate on your monitor's OSD.

Run FFXIV or Baldur's Gate 3 and refresh rate will stay at max refresh rate.

Crash reports, logs, images, videos

My hyprland config: hyprland.txt
Hyprland log when I was running Quake II RTX at lower graphical settings and refresh rate was stuck at 165hz: hyprland.log

[varris1]

I have tested several games and I also have the same problem. It depends from game to game if VRR works or not.

Version: Hyprland, built from branch at commit c4da4b026deefd58f532353b64e9f17130e760ca (). Date: 2024-01-12
Config: https://git.froggi.es/varris/nixos-dotfiles/src/branch/master/user/configs/wayland/hyprland/settings.nix

Games I've tested so far:

Factorio (Native) - doesn't work
Satisfactory (UE5, Proton) - works
Subnautica (Unity, Proton) - works
Dyson Sphere Program (Unity, Proton) - works
Avorion (Native) - doesn't work
Team Fortress 2 (Native) - doesn't work
Deep Rock Galactic (UE4, Proton) - doesn't work
Skyrim (Creation Engine, Proton) - works
X4: Foundations (Native) - works

[zakk4223]

It might be worth trying sway and seeing if the same issues persist. Sway has also had on-and-off issues with VRR framerates, and it seems to vary based on wlroots version/kernel version/mesa etc. It's kind of a mess, really.

A few things that may or may not help: try disabling direct scanout, try enabling software cursors, try disabling the atomic modesetting KMS api. scanout you can change with a hyprland config, and the other two are WLR_ environment variables

[NoisyFlake]

I have the same issue here on a 2070 Super, using the 535 dkms drivers. Anything below 144 FPS feels sluggish, because the monitor doesn't adjust correctly and just stays at 144Hz. It's definitely a Hyprland/wlroots issue, because it works fine on KDE X11 and KDE Wayland.

Things I've tried so far:

vrr = 1
allow_tearing = true
env = WLR_NO_HARDWARE_CURSORS,1
env = WLR_DRM_NO_ATOMIC,1
env = __GL_GSYNC_ALLOWED,1

I've verified that both vrr and tearing are active (via hyprctl monitors), so it should be working, but for some reason it doesn't. Right now I'm playing everything on lowest settings to achieve 144 FPS so that it doesn't feel sluggish, but of course that's not a long-term solution.

[Tractix]

I have the same issue here on a 2070 Super, using the 535 dkms drivers. Anything below 144 FPS feels sluggish, because the monitor doesn't adjust correctly and just stays at 144Hz. It's definitely a Hyprland/wlroots issue, because it works fine on KDE X11 and KDE Wayland.

Things I've tried so far:

vrr = 1 allow_tearing = true env = WLR_NO_HARDWARE_CURSORS,1 env = WLR_DRM_NO_ATOMIC,1 env = __GL_GSYNC_ALLOWED,1

I've verified that both vrr and tearing are active (via hyprctl monitors), so it should be working, but for some reason it doesn't. Right now I'm playing everything on lowest settings to achieve 144 FPS so that it doesn't feel sluggish, but of course that's not a long-term solution.

wlroots's (which is what Hyprland and Sway use) developers refuse to support NVIDIA so VRR and other features don't work at all.
Switch to KDE instead since they care about getting NVIDIA working on Wayland and from speaking to people on NVIDIA hardware using KDE (on wayland) it works well. VRR should also work on KDE (https://www.gamingonlinux.com/2024/01/nvidia-550-40-07-beta-driver-released-with-fixes-for-vrr-and-wayland/) but if it doesn't atleast you will get support in the near future even if it doesn't work now.

Also use a newer driver. Your driver is very outdated. VRR support landed only in 550 beta.
I recommend using https://github.com/Frogging-Family/nvidia-all to install the newest possible driver.

[Ricky12Awesome]

VRR works for me on nvidia 550, but only with 1 monitor enabled, same goes for KDE

Monitor 1: 2560x1440@170 freesync, connected via displayport (M27Q specifically)
Monitor 2: 3840@2160@60 idk, connected via hdmi (because the displayport on the monitor broke somehow)

[NoisyFlake]

Also use a newer driver. Your driver is very outdated. VRR support landed only in 550 beta. I recommend using https://github.com/Frogging-Family/nvidia-all to install the newest possible driver.

Using a newer driver on Wayland is not suitable for gaming until this is merged: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967

Everything above 535 results in black flickering every few ms, thus making every game unplayable. It seems there is no workaround for it yet, except manually compiling and installing this merge request.

[BlueskyFR]

@NoisyFlake the PR you mentionned applies to XWayland, so I guess Wayland-only stuff will remain broken even after it is merged right?

[NoisyFlake]

AFAIK yes, this only affects Xwayland.

Quick update from me: I've installed the latest 550 driver and the linked merge-request. While this improves the black flickering and performance, it's still more or less unplayable. IIRC, one of the NVIDIA devs said that a change in the NVIDIA drivers is also necessary for the issue to be completely fixed.

What I don't understand is why VRR seems to work just fine with the 535 drivers on e.g. KDE (both X11 and Wayland).

[freaky1337]

I am on kernel 6.8.1 with mesa 24.0.3 with the same gpu and I experience this too. In RDR2 it changes correctly, in Dead by Daylight it stays at max refresh rate. There is also a weird case with Robocop rogue city, I am getting around 70-100 fps there and according to my monitor's OSD, the refresh rate fluctuates between double of that, it's like LFC was kicking in or something.

[varris1]

I think I found out what causes VRR to not work on many games on my machine:

I have This animation rule set. The "loop" keyword seems to cause the problems on my end. Replacing "loop" with "once" (or removing the keyword entirely) completely fixed my VRR woes.

[Atemu]

Please ensure you're not running into https://gitlab.freedesktop.org/drm/amd/-/issues/1500.

echo 4 | sudo tee /sys/class/drm/card1/device/pp_power_profile_mode

[Atemu]

On the newest master with with #6877 and with a fix or workaround for https://gitlab.freedesktop.org/drm/amd/-/issues/1500, I cannot reproduce this issue.

VRR is still subtly broken but not nearly as massively as described here.