You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a random amount of time VRR seems to break entirely, after it breaks my monitor's OSD will only report a solid 143.9Hz and nothing seems to bring back proper functionality except for rebooting my PC. This isn't a new bug either as it has been plaguing me ever since I swapped to Hyprland earlier this year back in version 0.39 or so.
I can't seem to figure out a reason or pattern to it. But I have noticed two very strange things that happen after the bug has triggered and VRR is no longer functional:
hyprctl monitors still reports the monitors vrr status as vrr: true in scenarios where it should be, such as when an application is fullscreen with vrr = 2 set. Despite this, VRR is non functional and everything runs at 143.9Hz. (See video 1 below)
When using no_break_fs_vrr = true in fullscreen apps there seems to be large sections of the screen that are running at full refresh rate while other sections only refresh when they are supposed to. (See video 2 below)
This is different from how it functions normally (prior to the bug activating), where the entire window will render at the applications refresh rate or on static windows a multiple of what's set in min_refresh_rate which for me is 24 (See video 3 below)
Number 2 leads me to believe this has something to do with Hyprland rendering something (or some portion of the screen) at full refresh rate all the time once the bug occurs. Even odder is that this persists through disabling the screen in Hyprland, turning the screen itself off, and even exiting Hyprland and starting a new instance of it. I've not found a way of returing normal function outside of just plain restarting my PC.
Has anyone else experienced this? Previously Atemu reported something here #8382 that is similar to my experience in point 2 above except that VRR was still partially functioning, though he later went on to state that he couldn't reproduce it.
It doesn't seem to matter whether vfr is enabled or disabled either.
How to reproduce
I'm honestly unsure as it just seems to happen every now and then for me with no real obvious cause.
Use Hyprland for a while
Check if VRR is still functioning every now and then?
Crash reports, logs, images, videos
VRR entirely nonfunctional despite hyprctl monitors reporting the monitors vrr status as vrr: true and the game being in fullscreen:
20241117_032831.mp4
How a fullscreen application renders with no_break_fs_vrr = true after the bug has occurred:
20241117_034317.mp4
How a fullscreen application renders with no_break_fs_vrr = true normally and prior to the bug occurring:
20241117_035125.mp4
The text was updated successfully, but these errors were encountered:
Not a fix, but I have reliably not run into this issue since changing from vrr = 2 to vrr = 1. So there's something that goes wrong at some point when Hyprland attempts to enable or disable VRR that eventaully breaks it until a reboot. The downside of this workaround is that if you use vrr = 1 you will see the odd VRR flicker from time to time as the refresh rate jumps around as you do things on static screens.
Already reported ? *
Regression?
No
System Info and Version
System/Version info
Description
After a random amount of time VRR seems to break entirely, after it breaks my monitor's OSD will only report a solid 143.9Hz and nothing seems to bring back proper functionality except for rebooting my PC. This isn't a new bug either as it has been plaguing me ever since I swapped to Hyprland earlier this year back in version 0.39 or so.
I can't seem to figure out a reason or pattern to it. But I have noticed two very strange things that happen after the bug has triggered and VRR is no longer functional:
hyprctl monitors
still reports the monitors vrr status asvrr: true
in scenarios where it should be, such as when an application is fullscreen withvrr = 2
set. Despite this, VRR is non functional and everything runs at 143.9Hz. (See video 1 below)no_break_fs_vrr = true
in fullscreen apps there seems to be large sections of the screen that are running at full refresh rate while other sections only refresh when they are supposed to. (See video 2 below)This is different from how it functions normally (prior to the bug activating), where the entire window will render at the applications refresh rate or on static windows a multiple of what's set in
min_refresh_rate
which for me is 24 (See video 3 below)Number 2 leads me to believe this has something to do with Hyprland rendering something (or some portion of the screen) at full refresh rate all the time once the bug occurs. Even odder is that this persists through disabling the screen in Hyprland, turning the screen itself off, and even exiting Hyprland and starting a new instance of it. I've not found a way of returing normal function outside of just plain restarting my PC.
Has anyone else experienced this? Previously Atemu reported something here #8382 that is similar to my experience in point 2 above except that VRR was still partially functioning, though he later went on to state that he couldn't reproduce it.
It doesn't seem to matter whether
vfr
is enabled or disabled either.How to reproduce
I'm honestly unsure as it just seems to happen every now and then for me with no real obvious cause.
Crash reports, logs, images, videos
hyprctl monitors
reporting the monitors vrr status asvrr: true
and the game being in fullscreen:20241117_032831.mp4
no_break_fs_vrr = true
after the bug has occurred:20241117_034317.mp4
no_break_fs_vrr = true
normally and prior to the bug occurring:20241117_035125.mp4
The text was updated successfully, but these errors were encountered: