Fullsceen with VRR causes slow and stuttery cursor/mouse movement

[Arisa-Snowbell]

In recent commits something started causing mouse movement to be slow and stuttery if frame rate changes in any way, like going to 140 fps from 144 causes mouse movement and screen to look so bad, so stuttery and mouse movement super slow, some frame syncing or something I assume.
Don't have time to bisect it right now, maybe later on.
Anyone have idea what commit it could cause? I think it's something about syncing frames dunno

[neon-grim]

Edit: I've tracked this issue to commit 17e77e0. When starting a game with VRR active like warframe, cursor becomes extremely laggy with random slowdowns. Using gamescope seems to bypass the issue.

Edit2: I've discovered another issue which might be relevant to this. When running a game through proton using the wayland drivers, a similar issue can be observed. Mouse movement becomes stuttery and slowdowns can be observed. Though I have set to go into depth to test this.

I can confirm that this is also happening on my end, both with hardware and software cursor. I'm running the latest commit available through the nix flake to date.

One other curious thing I've noticed, was for some reason, disconnecting and reconnecting my mouse, resulted in the mouse input smoothing out. Though this also leads to the game window failing to capture the cursor. Once focus is lost and regained, the same stuttery behavior could be observed.

This might be caused by window focus? I've tried using different mouses, but the same issue could be observed. Additionally, when using a controller for camera input, the issue doesnt present itself.

[neon-grim]

I'm running waybar, but it never caused me problems, so I doubt its the cause of the issue with the latest release, especially since I'm still using the same waybar package with the downgraded version of hyprland.

Quickshell looks cool, but I'm trying to have everything GTK based on my system.

[LionHeartP]

I was suggesting more something like toggling waybar off and see if you can reproduce the issue.

[neon-grim]

reply to #12013 (reply in thread)

Yes, the issue still persists after killing waybar and starting the game without it active.

[neon-grim]

I've noticed that using gamescope also stops the issue from presenting itself. When under gamescope, camera movement while focused does no feel jittery or slow. It behaves as expected.

That said, there appears to be another issue when it comes to using gamescope + the latest version of hyprland as described in this issue I opened on the gamescope repo ValveSoftware/gamescope#2002.

[neon-grim]

reply to #12013 (reply in thread)

I was able to track the issue to a specific commit, which I've added to my first comment.

[neon-grim]

Edit: False alarm, it seems that the issue still persists when playing vulkan native games.

I've updated to commit 8e9add2 and it seems to resolve the issues introduced with commit 17e77e0. When using the afford mention commit, cursor seems to behave as expected when VRR is active. No stuttery / laggy cursor or slowdowns can be observed.

[shgew]

I’ve been seeing the same issue and wanted to add some details from my setup.

The problem shows up only when I use Proton + Wayland (for HDR) together with VRR enabled. Mouse input works on the first launch, but the moment the window loses focus even once, raw mouse look completely breaks.

What I see:
• The in-game menu cursor works normally, but camera look does not.
• Mouse movement is ignored until I click. When I click, the camera jumps to the new position as if the last movement delta gets applied all at once.
• Keyboard and controller inputs are fine. Controller gameplay is completely normal.
• If I start the game and never unfocus it, mouse look works, but it stutters as described in the other comments.
• I need to do windowed then fullscreen to get smooth mouse input again.
• Once the window loses focus after that, the mouse breaks again.
• Disabling VRR instantly fixes the mouse. Re-enabling VRR instantly breaks it again.

This only happens on Proton Wayland. It started about a month or two ago. HDR forces me to use Wayland driver, so that’s how I noticed it.

Happy to test patches or provide logs if needed.

[fxzzi]

try hyprctl keyword cursor:no_break_fs_vrr 0, its enabled by default on windows with content type game

[shgew]

Changing the condition from isConstrained to isLocked now makes all games I have tested to behave correctly -> shgew@28b8df6.

[shgew]

@UjinT34 This also works shgew@106ed38, as you have suggested.

At this point, I am quite lost on how to make this change production ready. If anyone has suggestions on where to break the cycle of pointer updates being endlessly buffered when the pointer is locked with VRR active, while not having to resort to updating at the mouse polling rate, please let me know :)

@UjinT34 what do you think about creating a no_break_fs_vrr=3 to explicitly handle this case?

[shgew]

I'm confused. Why would the code be unused? Shouldn't it still apply when no_break_fs_vrr=1 and the cursor isn't constrained? That sounds ideal for the issue I'm hitting at least.

I agree ☝🏻

[UjinT34]

I'm confused. Why would the code be unused? Shouldn't it still apply when no_break_fs_vrr=1 and the cursor isn't constrained? That sounds ideal for the issue I'm hitting at least.

That patch turns isLocked() && shouldSkipScheduleFrameOnMouseEvent() into isLocked() && !isLocked() which nukes all the code for locked cursors with no_break_fs_vrr. It doesn't affect unlocked cursors in any way.

@UjinT34 what do you think about creating a no_break_fs_vrr=3 to explicitly handle this case?

I'd rather add another setting, it should be easier to check and maintain.

Maybe someone is willing to go deeper and find out why pointer frame events with locked cursor result in an immediate frame callback. The entire hack is made to ignore those extra frames. And it seems that a locked cursor isn't the only condition for this to happen. Ideally we should avoid triggering those extra frames. If it's not possible then we should narrow the conditions for frame skipping.

[shgew]

I'm confused. Why would the code be unused? Shouldn't it still apply when no_break_fs_vrr=1 and the cursor isn't constrained? That sounds ideal for the issue I'm hitting at least.

That patch turns isLocked() && shouldSkipScheduleFrameOnMouseEvent() into isLocked() && !isLocked() which nukes all the code for locked cursors with no_break_fs_vrr. It doesn't affect unlocked cursors in any way.

@UjinT34 what do you think about creating a no_break_fs_vrr=3 to explicitly handle this case?

I'd rather add another setting, it should be easier to check and maintain.

Maybe someone is willing to go deeper and find out why pointer frame events with locked cursor result in an immediate frame callback. The entire hack is made to ignore those extra frames. And it seems that a locked cursor isn't the only condition for this to happen. Ideally we should avoid triggering those extra frames. If it's not possible then we should narrow the conditions for frame skipping.

Alrighty. Thanks for the guidance.

[Arisa-Snowbell]

I had it happen on XWayland for me when I reported it, I was aware of Wine Wayland issue, after doing my usual round of updates, recompiling kernel and mesa from scratch, restarted and it worked fine on XWayland, no idea what it was.

[dablenparty]

I've been regularly using VRR and HDR together (on an NVIDIA card) for the past ~2 months and have not experienced this, so I think it's important that @shgew had this issue crop up around the same time I got it working. I understand that you've found a "problematic" commit, but the fact that gamescope bypasses this for you makes me think it's not Hyprland... are you sure this isn't just a Wine/Proton issue? I think we need more info like everyone's GPU, what window rules we all apply to our game windows, and lastly our launch arguments and Wine/Proton versions. I fixed a LOT of my own problems by using Proton GE and setting my primary monitor with xrandr and the envvar WAYLANDDRV_PRIMARY_MONITOR.

I have an NVIDIA 3080 Ti and use either Proton GE 10-25 or the latest proton-cachyos. My HDR launch args and window rules (adapted to the new syntax) are below.

Relevant Window Rules

$steamAppClass = ^steam_app(_\d+|default)?$

# Content Types
windowrule = match:xdg_tag ^(proton-game)$,              tag +video-game
windowrule = match:content 3,                            tag +video-game
windowrule = match:initial_class $steamAppClass,         tag +video-game
windowrule = match:initial_class ^(.*\.exe)$,            tag +video-game
# just add the names of modpacks
windowrule = match:initial_title ^(Minecraft|Tekxit).*$, tag +video-game
windowrule = match:initial_class ^(artofrally).*$,       tag +video-game

# Game Window Rules
# default monitors are handled by proton.zsh

workspace = 10, defaultName:Gaming, border:false, shadow:false, rounding:false, decorate:false, gapsin:0, gapsout:0

windowrule {
    name = video-games
    match:tag = video-game
    match:workspace = name:Gaming
    workspace = name:Gaming

    border_size = 0
    decorate = false
    force_rgbx = true
    fullscreen = true
    # using 2 2 doesn't work for some games *cough* ELDEN RING
    fullscreen_state = 3 3
    idle_inhibit = always
    immediate = true
    no_anim = true
    no_blur = true
    no_dim = true
    no_max_size = true
    no_shadow = true
    persistent_size = true
    pseudo = true
    render_unfocused = true
    rounding = 0
    # fixes games that fail to maximize *cough* ELDEN RING
    sync_fullscreen = true
}

Launch Args

game-performance is the CachyOS variant of gamemode; it is not gamescope.

PROTON_ENABLE_NVAPI=1 PROTON_NO_WM_DECORATION=1 PROTON_NVIDIA_LIBS=1 PROTON_PREFER_SDL=1 DXVK_HDR=1 ENABLE_HDR_WSI=1 PROTON_ENABLE_HDR=1 PROTON_ENABLE_WAYLAND=1 WAYLANDDRV_PRIMARY_MONITOR="DP-3" PROTON_USE_NTSYNC=1 game-performance %command%

[adamnejm]

are you sure this isn't just a Wine/Proton issue

Surely not, I'm also experiencing this on Nvidia when playing Deadlock.
PROTON_ENABLE_WAYLAND=1 mangohud gamemoderun %command% -vulkan +citadel_unit_status_use_new true

It works fine on Plasma, but I get an actual headache when playing for more than 5 mintues on Hyprland.

[UjinT34]

I'm also experiencing this on Nvidia when playing Deadlock.

Try with PROTON_ENABLE_WAYLAND=0. If this helps then the hack should be applied for xwayland clients only.

[adamnejm]

Yes, using XWayland prevents the issue from happening.

Also,

False alarm, it seems that the issue still persists when playing vulkan native games.

It's happening for both Vulkan and DX11, at least in Deadlock.

[shgew]

Can confirm that shgew@89954fc works just as well.
@UjinT34 would you consider this worthy of merging?

[UjinT34]

lgtm

[shgew]

Opened a PR with a fix #12402.

[Szwagi]

I have this issue with CS2 (SDL_VIDEODRIVER is set to Wayland).
I moved from v0.52.2 to main (which includes #12402) and it did not resolve my issue.

When VRR is on and FPS is not 354FPS (360Hz screen), the sensitivity is slower than it should be.
Under extreme conditions like 180FPS or 720FPS, the sensitivity is almost half.
This does not happen on KWin.

I do not have the issue when running the game through Gamescope.
Unsure if related, but Gamescope requires the --force-grab-cursor flag for the game to work correctly at all, or the camera get stuck if I move my mouse to rotate more than 20 degrees, like the cursor hits the edge of the screen or something.

I have tried experimenting with disabling hardware cursors as suggested somewhere in here, nothing helps.

windowrule = match:class gamescope,        fullscreen true, workspace 19, content game
windowrule = match:class cs2,              fullscreen true, workspace 19, content game

cursor {
}

misc {
    vrr = 3
}

input {
    sensitivity = 0
    accel_profile = flat
}

One other curious thing I've noticed, was for some reason, disconnecting and reconnecting my mouse, resulted in the mouse input smoothing out. Though this also leads to the game window failing to capture the cursor. Once focus is lost and regained, the same stuttery behavior could be observed.

I can confirm this happens to me as well. When I reconnect my mouse, the sensitivity is correct till I open a menu or the cursor leaves the game window onto my second monitor (it does so even when I'm rotating my camera).

[Szwagi]

Okay, so I somehow missed setting no_break_fs_vrr = 1... Might have had a bad combination of other variables when I tried that before. However, this does not make much sense to me, why does not sending frames to the display make the game not receive the mouse inputs? I assume this will delay game rendered frames and insert duplicates simply because I moved my mouse?
At this point I don't know if this is even related to this discussion, let me know if it's worth making a new discussion for.
Edit: I have read, I did try it before, multiple times (been staring at the Variables page in wiki for a while on my own too). I only tried again now after seeing it in another discussion that specifically mentioned CS2.

[fxzzi]

please read this discussion again. All info is already provided here. A PR has already been pushed to the repo to fix the problem. The reason for the problem has already been explained above.

[Szwagi]

please read this discussion again. All info is already provided here. A PR has already been pushed to the repo to fix the problem. The reason for the problem has already been explained above.

I have reread everything and didn't find anything but #13402. GitHub is a bit annoying with hiding half of the discussion so I might have missed something again?

As I said in my comment, I am running the main branch, which has the patch you mention.

Hyprland 0.52.0 built from branch main at commit 69db0bcae640410b6c587cb0ffd0c89bc8166ff0 dirty (compositor: early return on no monitor ( 12637)).

My experience WITH THE PATCH:
no_break_fs_vrr = 1 - Mouse input is wrong.
no_break_fs_vrr = 0 - The sensitivity is normal, but the monitor reports 357FPS when moving the mouse (300FPS cap otherwise). Which I assume results in duplicate frames being sent, which isn't necessary with VRR, delaying display of other frames.

This is exactly the same as on v0.52.2.
In Plasma the monitor reports 300FPS even while moving the mouse.

Is what I'm seeing expected? As far as I can tell I am seeing an issue, I'm just a bit confused if it's the issue that's being discussed here, as I am not seeing a difference with the patch.

[UjinT34]

Depends on a game (locked/unlocked cursors, ingame sensetivity and acceleration), hw/sw cursors and wayland/xwayland. no_break_fs_vrr = 0 is expected to jump to max refresh rate when mouse moves - cursor updates asap and should be smooth in any circumstances. no_break_fs_vrr = 0 with locked hw cursors under xwayland will buffer mouse movements and send the result on the next frame - framerate should be steady, mouse movements might be erratic for some games in combination with some cursor acceleration and smoothing settings. All those vrr shenanigans are only meant for monitors that can't handle rapid rate changes and have brightness fluctuations. And it somewhat defeats the purpose of hw cursors (update cursor position asap regardless of the fps).
Avoid locked hw cursors under xwayland combination or get a better monitor and set no_break_fs_vrr = 0. The latter option should be better for your eyes overall.

[Szwagi]

I just sat down to debug the sensitivity issue. I'm not familiar with the codebase, but I found a solution that seems to fix the issue on my setup. no_break_fs_vrr = 1, monitor reports 300FPS on 300FPS cap as expected, and the sensitivity is consistent.

Seems like Hyprland eats stored mouse movement whenever it skips the frames.

--- a/src/InputManager.cpp
+++ b/src/InputManager.cpp
@@ -131,10 +131,7 @@ void CInputManager::onMouseMoved(IPointer::SMotionEvent e) {

     const auto DELTA = *PNOACCEL == 1 ? unaccel : delta;

-    if (g_pSeatManager->m_isPointerFrameSkipped)
-        g_pPointerManager->storeMovement(e.timeMs, DELTA, unaccel);
-    else
-        g_pPointerManager->setStoredMovement(e.timeMs, DELTA, unaccel);
+    g_pPointerManager->storeMovement(e.timeMs, DELTA, unaccel);

     PROTO::relativePointer->sendRelativeMotion(sc<uint64_t>(e.timeMs) * 1000, DELTA, unaccel);

--- a/src/PointerManager.cpp
+++ b/src/PointerManager.cpp
@@ -935,8 +935,11 @@ void CPointerManager::attachPointer(SP<IPointer> pointer) {
             }
         }
         g_pSeatManager->m_isPointerFrameSkipped = shouldSkip;
-        if (!g_pSeatManager->m_isPointerFrameSkipped)
+        if (!g_pSeatManager->m_isPointerFrameSkipped) {
             g_pSeatManager->sendPointerFrame();
+            g_pPointerManager->m_storedDelta = {};
+            g_pPointerManager->m_storedUnaccel = {};
+        }
     });

     listener->swipeBegin = pointer->m_pointerEvents.swipeBegin.listen([](const IPointer::SSwipeBeginEvent& event) {
@@ -1128,4 +1131,3 @@ void CPointerManager::sendStoredMovement() {
     m_storedDelta   = Vector2D{};
     m_storedUnaccel = Vector2D{};
 }