PoC Fix VRR for constrained cursors

[UjinT34]

Describe your PR, what does it fix/add?

• allows cursor:no_break_fs_vrr to work with locked cursors
• skips window z order changes if window is in correct position
• uses m_pLastMonitor instead of getMonitorFromCursor with locked cursor in some places

When cursor is constrained (and maybe also locked) g_pSeatManager->sendPointerFrame() results in an extra listener_commitWindow call which schedules a frame for monitor. These extra frames break VRR. #5918 (comment)
Since there is no direct connection (at least I couldn't find one) between sendPointerFrame and listener_commitWindow and the latter also happens when an app sends a new frame it is hard to filter unnecessary frame schedules.

This PR delays sendPointerFrame to be called when an app sends a new frame and then skips the damage from next listener_commitWindow. This fixes VRR but loses most of the cursor movement between the frames.
I don't think that it is the correct way to fix this issue. If it is possible to not get those extra window commit events than it will be a better solution.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

If something is wrong with this PR as a whole consider cherry-picking 05de4f3
if clicked on a floating window make it top comment is misleading. changeWindowZOrder is called for every clicked window. Is it intended behaviour or a bug?
CInputManager::onMouseMoved might set the cursor position outside the constraint. Some code uses this incorrect position before the constraints are handled. This PR fixes several of such situations. There might be more.

Works more reliable when the app is the only one on its workspace.

Is it ready for merging, or does it need work?

Ready if there is no better way to do it.

• check this hack is disabled when vrr = 0
• test GW2
• deal with movement speed
• test games on special workspaces
• fast mouse movement can briefly jump outside of constraint

[myned]

With this PR, vrrtest on a regular workspace with the below relevant config plus vrr = 2 results in:

• No cursor movement = functional VRR
• Cursor movement = lowered framerate while moving despite software cursors and no_break_fs_vrr
• Mouse clicking = refresh rate spikes consistent with the main issue

hyprland.conf

... omitted: exec-once

plugin=/nix/store/4ciqvzb102b03k8gx3qsirvnbm0wn9bh-hyprbars-0.1/lib/libhyprbars.so
binds {
  allow_workspace_cycles=true
  disable_keybind_grabbing=true
  scroll_event_delay=0
}

cursor {
  hotspot_padding=10
  min_refresh_rate=0
  no_break_fs_vrr=true
  no_hardware_cursors=true
  no_warps=true
  zoom_rigid=true
}

decoration {
  blur {
    enabled=false
  }
  col.shadow=rgba(00000040)
  col.shadow_inactive=rgba(0000001a)
  dim_special=0.500000
  rounding=16
  shadow_range=50
  shadow_render_power=4
}

device {
  name=kensington-orbit-wireless-tb-mouse
  accel_profile=adaptive
  left_handed=true
  middle_button_emulation=true
  natural_scroll=true
  sensitivity=-0.500000
}

device {
  name=logitech-m570
  accel_profile=adaptive
  sensitivity=-1
}

device {
  name=wireless-controller-touchpad
  enabled=false
}

general {
  border_size=2
  col.active_border=rgb(93a1a1)
  col.inactive_border=rgba(93a1a140)
  col.nogroup_border=rgba(dc322f40)
  col.nogroup_border_active=rgb(dc322f)
  gaps_in=10
  gaps_out=20
  layout=master
  resize_on_border=true
}

gestures {
  workspace_swipe=true
  workspace_swipe_cancel_ratio=0.200000
  workspace_swipe_distance=1000
  workspace_swipe_forever=true
  workspace_swipe_min_speed_to_force=10
}

group {
  groupbar {
    col.active=rgb(6c71c4)
    col.inactive=rgba(6c71c440)
    col.locked_active=rgb(d33682)
    col.locked_inactive=rgba(d3368240)
    font_size=12
    height=10
    render_titles=false
    text_color=rgb(93a1a1)
  }
  col.border_active=rgb(6c71c4)
  col.border_inactive=rgba(6c71c440)
  col.border_locked_active=rgb(d33682)
  col.border_locked_inactive=rgba(d3368240)
  insert_after_current=false
}

input {
  touchpad {
    clickfinger_behavior=true
    natural_scroll=true
    scroll_factor=0.300000
  }
  accel_profile=flat
  float_switch_override_focus=0
  follow_mouse=1
  mouse_refocus=false
  repeat_delay=400
  repeat_rate=40
  sensitivity=0.500000
}

master {
  always_center_master=true
  mfact=0.500000
  new_on_active=before
  orientation=center
}

misc {
  background_color=rgb(073642)
  disable_hyprland_logo=true
  disable_splash_rendering=true
  focus_on_activate=true
  font_family=Iosevka NF SemiBold
  force_default_wallpaper=0
  initial_workspace_tracking=0
  key_press_enables_dpms=true
  middle_click_paste=false
}

plugin {
  hyprbars {
    bar_button_padding=12
    bar_color=rgb(002b36)
    bar_height=36
    bar_padding=12
    bar_precedence_over_border=true
    bar_title_enabled=false
    hyprbars-button=rgb(dc322f), 16,, /nix/store/wcwpgpb6ragsn2vz96r19xp2fr4l2x6d-hyprland-0.41.2/bin/hyprctl dispatch killactive
    hyprbars-button=rgb(d33682), 16,, /nix/store/wcwpgpb6ragsn2vz96r19xp2fr4l2x6d-hyprland-0.41.2/bin/hyprctl dispatch fullscreen 1
    hyprbars-button=rgb(6c71c4), 16,, minimize
  }
}

xwayland {
  force_zero_scaling=true
}
animation=global, 1, 5, default
animation=specialWorkspace, 1, 5, default, fade

... omitted: bind, envd, exec-once, windowrulev2, workspace

[myned]

To address the rest of the tests:

• vrr = 0 correctly disables VRR with no cursor side effects

With vrr = 2, = 1 not tested:

• GW2 is <1 fps while moving cursor with min_refresh_rate = 0, = 60 results in dropping to 60 during movement, followed by a large stutter when stopping movement that seems visually identical to mouse click
• GW2 has large stutters when clicking mouse, unsure if framerate or refresh rate as I do not have a monitor OSD
• Cursor update speed does seem lower than the current framerate while VRR is active
• VRR with vrrtest does not work in a special workspace

[UjinT34]

GW2 internal fps limit doesn't seem to do a good job, fps fluctuates around the limit. Mangohud limit fixes that.
Can't reproduce mouse click issues in GW2.

cursor:no_break_fs_vrr works only on regular workspaces. Is there any need to have it on special?

Note that there is an issue with switching vrr from 2 to 1 #6893
This fix and cursor:no_break_fs_vrr doesn't rely on vrr setting. They check the real adaptive sync status.

[myned]

GW2 internal fps limit doesn't seem to do a good job, fps fluctuates around the limit.

Their limiter is pretty awful even on Windows. Before the latest commit, I retested with the MangoHUD limiter globally enabled with the result:

• vsync on = same issues mentioned above
• vsync off = vrr works without stutter, but when panning camera with mouse it is drastically slower, though still matched framerate to refresh rate. The cursor itself is unaffected

After f412e11, all previously mentioned issues with GW2/vrrtest except the mouse clicks causing refresh rate to jump seem to be fixed.

Can't reproduce mouse click issues in GW2.

I reproduced on vrrtest (and GW2 as well) both before and after the latest commit by:

• Set vrr = 2
• Launch vrrtest > lower target framerate from max
• Click anywhere
• Observe refresh rate spiking likely to max from the target framerate

I cannot verify the exact numbers due to the lack of an OSD. On my system the spikes manifest as backlight flickering.

cursor:no_break_fs_vrr works only on regular workspaces. Is there any need to have it on special?

I only mentioned special workspaces in case it was not intentional for vrr to be broken in them given that fullscreen is possible. It is not working even without cursor movement, irrespective of no_break_fs_vrr.

Subjectively, I would expect any type of workspace to behave similarly and I have a preference for using scratchpads where possible, but named workspaces are fine. Perhaps a name change from "special workspace" could be justified if it's not planned to make them have feature parity (or if it's not possible).

Note that there is an issue with switching vrr from 2 to 1 #6893

I tested solely with vrr = 2 and switched between vrr = 0 for this reason.

This fix and cursor:no_break_fs_vrr doesn't rely on vrr setting. They check the real adaptive sync status.

Understood. I was mainly referring to the vrr keyword in reference to disabling with 0.

[UjinT34]

This PR shouldn't change the vrrtest behaviour.
Still can't detect any spikes when clicking. Does this happen with mouse or with touchpad?

[myned]

I wasn't sure initially, but the latest commit reverted functionality to the same as Hyprland main @ bd52682, as far as I can tell. The spikes happen on both main and this PR for my system. It does not occur with a bluetooth controller nor the keyboard. None of the usual suspect keywords (under general, input, misc, or cursor) seem to have an effect on whether it spikes on click.

Tested with hardware:

• Razer Viper Ultimate in wireless mode, all buttons including side
• Kensington Orbit trackball, both buttons
• AMD RX 6750 XT with pp_power_profile_mode = 1
• Samsung S34CG50 monitor @ 48?-100hz, target framerate set to 60

[Gwenodai]

I can confirm what Myned is saying. Clicking M1, M2, M3 (mmb), M4, or M5 cause refresh rate spikes. as seen in the video below

20240716_182449.mp4

On the other hand I've noticed another bug happening with mouse movements that I'd not encountered before. With no_break_fs_vrr = true mouse movements in any direction except right are fine. However moving right which is the direction of my second monitor causes spikes. I've also tested changing the position of my monitors and it moves the trouble direction as you'd expect. Clip below

20240716_182921.mp4

This can be mitigated by leaving a large gap between monitors (0x0 and 2000x0 vs 0x0 and 1920x0), however this means that you have to move the mouse fast to move between monitors normally and also means that you still get spikes when moving the mouse fast enough to that side. So this leads me to believe that the mouse is leaving the game and moving to the other monitor briefly which is what's causing the spikes in this case.

Also I don't know if this is supposed to be the case for no_break_fs_vrr = false on this pr or on the latest git, but with that disabled my refresh rate sits at 144 when moving the mouse at all in fps games despite it being invisible anyway.

[Gwenodai]

Also I don't know if this is supposed to be the case for no_break_fs_vrr = false on this pr or on the latest git, but with that disabled my refresh rate sits at 144 when moving the mouse at all in fps games despite it being invisible anyway.

Ok after a quick test I can confirm this is just how Hyprland functions now on the latest git no matter the state of no_break_fs_vrr. On the latest git no matter what settings used Hyprland will sit at max refresh rate when moving the mouse in fps games. On this PR, no_break_fs_vrr=true fixes this with the added issues of the second clip I explained in my previous comment.

This PR shouldn't change the vrrtest behaviour.
Still can't detect any spikes when clicking. Does this happen with mouse or with touchpad?

Just to clarify, the mouse button spikes Myned and I mentioned have been a thing in all Hyprland versions I've ever used. I don't think this PR has anything to do with that. Recent Hyprland versions prior to this PR just don't work with vrr at all when looking around in games so that might have made it harder to notice the mouse button thing between 0.41.0 and this PR where vrr had completely broken.

[UjinT34]

Does the spike happen on mouse down, mouse up or both? Can't test it myself, my osd doesn't refresh itself and I don't see such short spikes.
This PR requires cursor:no_break_fs_vrr = true.
LFC might work incorrectly for some setups. This is a hw or driver issue. My monitor advertises 48hz min refresh but starts doing weird stuff when fps goes below 52.

[Gwenodai]

Does the spike happen on mouse down, mouse up or both?

I can test this tomorrow. But I'm not sure considering it doesn't happen on every single input as you can see from the video I posted. Which is just really odd.

[myned]

The spike occurs on mouse down only, for barely a millisecond as indicated above. Movement while mouse down does not incur additional spikes. If I had to guess it could've been a bind, but it still happens with all binds and window rules excluded from the config. I also tested without building with hyprbars to the same effect.

I cannot test the multi-monitor issues as I only have one display.

Additionally, I don't use vrr = 2 for general usage anymore as my entire system regularly freezes when VRR is active (only with fullscreen apps such as games or video in a browser). It just happened recently while testing in vrrtest, so it is not fixed in recent versions. There are no logs and I cannot SSH into the machine nor switch to a different TTY, requiring a hard reset.

hyprctl systeminfo

Hyprland, built from branch  at commit f412e11aa530650a37080edd834dcec7fd7b38b5  ().
Date: 2024-07-15
Tag: , commits: f412e11aa530650a37080edd834dcec7fd7b38b5

flags: (if any)


System Information:
System name: Linux
Node name: mynix
Release: 6.9.8-zen1
Version: #1-NixOS ZEN SMP PREEMPT_DYNAMIC Tue Jan  1 00:00:00 UTC 1980


GPU information: 
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT] [1002:73df] (rev c0) (prog-if 00 [VGA controller])


os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.11.20240714.693bc46"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.11 (Vicuna)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.11 (Vicuna)"
VERSION_CODENAME=vicuna
VERSION_ID="24.11"


plugins:
  hyprbars by Vaxry ver 1.0

(Edited for clarity)

[myned]

Some additional testing in vrrtest:

• Dispatcher does not spike via watch -n 1 'hyprctl dispatch sendshortcut , mouse:272, class:love'
• Hardware scroll wheel does not spike in either direction (but middle mouse still does)

[Atemu]

I can reproduce the mouse click issue but only in some games and combinations of windowed/fullscreen.

---

What's worse though is that VRR doesn't appear to work properly without inputs to begin with:

When I run vrrtest at 139 fps, actual vfreq is 144 and stutters ~twice a second.

When I run vrrtest at 130 fps, actual vfreq jumps between 144~130 and sometimes dips far below into the 80s-90s, quite stuttery overall.

When I run vrrtest at 75 fps, actual vfreq appears to be quite stable but actually jumps around very often (causing stutter) and results in jumps to 90~100 in vfreq from time to time.

(Vsync on and AMDGPU in the VR power profile (4).)

---

BTW, if you have an LG monitor, the debug menu has a more frequent vfreq display without as much averaging that also stays on screen permanently via the service menu. Power off, left, left, left, right, power on and then settings, debug info.

Other monitors may have similar service menus.

[myned]

@Atemu

but only in some games and combinations of windowed/fullscreen.

If you're using vrr = 1, there are still many events that can interrupt the stability of VRR in windowed mode outside of input, as commented. This can cause issues without proper direct scanout, if I understand correctly, and is worth revisiting after the wlroots migration. If vrr = 2, you wouldn't have VRR active without fullscreen, which would cause stutter. I'd suggest testing only with vrr = 2 for the purposes of this PR.

[Gwenodai]

It's definitely on mouse down for me too. Oddly enough, I found a "fix" for this back in 0.40.0 but that doesn't work on this PR. I'm not sure when that changed as I've been sticking with 0.40.0 since it's the last good vrr build I've found on my testing.

What's worse though is that VRR doesn't appear to work properly without inputs to begin with:

When I run vrrtest at 139 fps, actual vfreq is 144 and stutters ~twice a second.

When I run vrrtest at 130 fps, actual vfreq jumps between 144~130 and sometimes dips far below into the 80s-90s, quite stuttery overall.

When I run vrrtest at 75 fps, actual vfreq appears to be quite stable but actually jumps around very often (causing stutter) and results in jumps to 90~100 in vfreq from time to time.

I can't reproduce this at all. My vfreq on all values in vrr test and other applications is within +-1hz from the reported fps. The only change is below 51fps when LFC kicks in, though oddly enough LFC is supposed to be 48 but idk.

[myned]

@Atemu

Also, in most games, VSync adds additional overhead without benefit for adaptive refresh, and vrrtest runs by default with it disabled. If there's no difference, it's usually better to disable it.

[myned]

@Gwenodai

Your linked comments sound like fullscreen wasn't being enabled. Did you confirm that VRR is active while the spikes do not occur? A decent way to visually see whether the window is fullscreened properly is with reserved space such as overlays (e.g. waybar). Generally, with normal workspaces, if the overlay is not hidden, the window isn't in true fullscreen.

[Gwenodai]

@myned

Yes I can confirm fullscreen was enabled and that vrr was functioning in both instances. I usually limit the fps to 60 or something in the high double digits when testing to make it very easy to tell if spikes occur both visually and by watching the reported vfreq spike from 2 digits to 3 digits. I have waybar at the top of my screen, it is not visible during fullscreen. On top of that, the testing to confirm that was done with the help of hyprctl's activewindow output which confirms that in all cases the application was in proper fullscreen.

I have no idea why "floating": true has any effect on a fullscreen window, but it is consistent and reproducible on 0.40.0 for me. In fact I'll include a video of it to demonstrate it.

20240717_155126.1.mp4

This video was taken on a regular workspace with vfr = 1, vrr = 2, and no_direct_scanout = false on Hyprland 0.40.0 with vrrtest set to 87fps. The first and third tests have the properties of "floating": true, "fullscreen": true, "fullscreenMode": 0. The second one has the properties of "floating": false, "fullscreen": true, "fullscreenMode": 0.

As you can see this bug is completely eliminated under these circumstances on 0.40.0. This however does not prevent it on this PR, so something has changed since then. This however really shouldn't be necessary and makes no sense as to why it works. But the weird thing is that it does and because of that I've written a script that checks for floating on fullscreen game windows and fixes it for me, essentially eliminating the bug in a hacky behind the scenes way for me. However since discovering this back on June 22nd I've not been effected by the spikes again until trying this new PR.

EDIT: Just to add on another weird vrr oddity, 0.40.0's declaring the cursor_inactive_timeout variable causes vrr = 2 to stop functioning after it hides the cursor for me. Setting it to cursor_inactive_timeout = 0 or just not having it works fine. But say I set it to 3 seconds, vrr works fine until that 3 second timer since mouse movement ends in which case the cursor disappears and the vfreq sits at 143.9hz indefinitely. So there's quite a few odd interactions with vrr in Hyprland, though I'm not sure if that still exists on later builds.

[UjinT34]

Do mouse clicks cause spikes with input:follow_mouse = 3?

[myned]

Do mouse clicks cause spikes with input:follow_mouse = 3?

They do not! Looks like it's related to focus as cyclenext while vrrtest is the only window also triggers the spike.

I can also confirm that follow_mouse = 3 works on v0.40.0 as I was testing the floating fix mentioned, without being able to reproduce.

[Gwenodai]

Do mouse clicks cause spikes with input:follow_mouse = 3?

No they do not. So it appears mouse buttons must be doing something like shifting the focus or refocusing for a single frame. Then why does this behaviour not happen on fullscreen applications in 0.40.0 when "floating": false?

For reference I use follow_mouse = 1

[UjinT34]

Looks like these spikes are caused by refocus or bringing a floating window to top.

[Gwenodai]

@UjinT34

Then wouldn't mouse_refocus = false solve the issue with follow_mouse = 1? Because it seems to have no effect for me.

[myned]

My bad, it does indeed spike on alterzorder. I had it bound to the same key as cyclenext.

[myned]

@Gwenodai

As for floating: 0 not causing spikes, I believe that's due to some configuration differences as I wasn't able to reproduce myself.

Best guess would be this rule from your posted config, which would mean tiled windows might paint differently than floating ones (possibly being related to multi-monitor as well):

windowrulev2 = bordercolor rgba(00fbff85),fullscreen:1

[Gwenodai]

@myned

It may well be something in my config, but it's definitely not that as that only changes the border color of maximized windows not fullscreened ones and removing that has no effect.

The odd thing is nothing in my config changes between Hyprland versions outside of env = WLR_NO_HARDWARE_CURSORS,1, default_cursor_monitor = DP-1, cursor_inactive_timeout = 0 being removed from my config and these being added to cursor: no_hardware_cursors = true, inactive_timeout = 0, default_monitor = DP-1, no_break_fs_vrr = true, min_refresh_rate = 48

[myned]

Retested @ 7dc595e, seems to be working the same as before aquamarine in both vrrtest and GW2. The occasional stutter is still present, but that's likely due to external factors outside of Hyprland's control, such as hardware.

@Atemu

Or is that behaviour due to usage of a HW cursor?

From my understanding, the difference in behavior you're seeing is indeed because of hardware cursors, due to them being on a separate plane than the main framebuffer, thus can be updated independently at a multiple of the main framerate (LFC).

X11 and Windows may have the ability to update cursors as a multiple of refresh without triggering a page flip (which discards the previous frame), but it seems that Wayland does not currently have an API path to do so, though I was unable to confirm this. zamundaaa from KDE explains it better than I can - by "AMS API" I believe they mean AMD, so FreeSync only.

cursor:min_refresh_rate is needed for software cursors because it's a single framebuffer for both cursor and application, which can be under minimum refresh, and is essentially a workaround for cursor movement not refreshing the display, but is not dynamic like with LFC and hardware cursors.

According to a thread in that issue, a type of pseudo-LFC could theoretically be implemented by a compositor, where the frame could be repeated at the highest supported multiple with an updated cursor position instead of relying on the monitor's handling below minimum refresh, which would also work for software cursors, but this was not expanded upon further from what I could find.

Disclaimer: I am paraphrasing quite a lot here, but I tried to compile as much info as possible since LFC is such a misunderstood topic in the general VRR space (and possibly by myself).

@UjinT34

If you haven't seen it already, KWin has some additional context that may be worth looking at, and some potential options for working around hardware cursors here.

[Atemu]

zamundaaa from KDE explains it better than I can - by "AMS API" I believe they mean AMD, so FreeSync only.

AMS likely means atomic mode setting in this context.

The thread linked is very helpful because they had to solve the exact same issue at hand here and the currently chose workaround was also presented as one of the options.

[Atemu]

The newest version does not appear as smooth as the previous iteration anymore. When moving the camera around in Planetside 2 at a locked 7.2ms (Mangohud shows variation of 7.1~7.2), refresh rate often jumps between 137Hz and 143Hz though it appears to primarily focus around 138.something and 139.something. It feels off too, this is not an accurate representation of the frame rate.

It's not easy to tell in vrrtest but if you make it fluctuate a bit (I chose 120 min 139 max), you can tell it judders a bit with a frequency of roughly ~4Hz but it's not constant. Super hard to tell reproducibly but irritating in practice.

[Atemu]

I tried the previous version again (7dc595e) and it does indeed feel better, so I wasn't imagining it.

However, it also shows the issue I noticed on the newer version with the refresh rate jumping a bit. Though it appears not quite as much? It's that hard to tell.

The small judder is not visible in vrrtest however (or at least not to a noticeable degree).

[UjinT34]

The newest version is rebased on main and doesn't change anything for sw cursors. Adds some skips for hw. If there is a regression then it comes from changes on main.

[myned]

vrrtest and GW2 @ 3d3955f

I don't notice anything different with software cursors myself and rapid fluctuations would result in pretty noticeable flicker on my monitor.

With hardware cursors it still fluctuates on cursor movement, but very minorly and only in GW2. When the cursor is locked there is no noticeable difference to software cursors, so that's great.

[Atemu]

A merge conflict arose btw.

[Gwenodai]

Is this still being worked on? I miss having reliable vrr in hyprland without having to swap between versions depending on what input device I want to use.

[UjinT34]

This is ready to be merged if there no other way to get rid of unwanted _CWlSurfaceCommit calls. Still might not work for every game #7386

[Cloudperry]

Tested this PR to see how games work with it. Quake champions worked well, but Apex legends was very laggy with this PR compared to main branch. I can't really check if vrr is working, because my monitor doesn't have an fps overlay, but I didn't notice any tearing with allow_tearing on. I can maybe add some logs or other details about the Apex legends issue later. Basically the game is running well (Mangohud frametimes), but appears extremely stuttery and possibly shows out of order frames.

I also checked if this happens to fix #7414, but it didn't.

[Atemu]

@Cloudperry Have you ensured you're not running into https://gitlab.freedesktop.org/drm/amd/-/issues/1500?

Also look up whether there's a debug/service menu for your display which shows this info. I believe all of them do for QA purposes but it's not always documented (usually unofficially).

[Cloudperry]

@Cloudperry Have you ensured you're not running into gitlab.freedesktop.org/drm/amd/-/issues/1500?

Also look up whether there's a debug/service menu for your display which shows this info. I believe all of them do for QA purposes but it's not always documented (usually unofficially).

I have ran into that quirk before and fixed it, but actually that was the cause. My Corectrl autostart was somehow broken. Now VRR is working really nicely (no tearing when allow_tearing is on) with games capped to 142 fps using Mangohud. On main branch with no_break_fs_vrr I had occasional tearing with the same games, but that testing was with a 143 fps cap.

[Keksmo]

when can we expect this to be merged? I would really love to see vrr working on the current build

[vaxerski]

idk it's still a PoC

[Atemu]

FWIW, this makes VRR work much better than it did before; it's quite essential honestly.