DS doesn't work with SW cursors. Might work with invisible SW cursors if the code allows it.
HW cursor movement breaks vrr on nvidia-drm (probably driver issue with atomic commit and cursor plane properties).
Locked cursors are handled differently withno_break_fs_vrr = 1. Might be the source of issues since tearing is usually needed for FPS games and they use locked cursors.

is there still any blocking for this PR? I've been using this patch for weeks and it's okay.

is there still any blocking for this PR? I've been using this patch for weeks and it's okay.

I don't think its finished, gotta look over it still

@ikalco rebase?

rebase possible? ty ikalco

I tried this on top of Hyprlanddd33128 and it didn't seem to work properly. (This is the first time I have tested this PR.)

When I started a fullscreen gamehyprctl monitors showed the same hex value on solitary and directScanoutTo. I guess this means that direct scanout was active. There were some graphical glitches and stuttering while it was active and I moved the mouse. When I went in game and the cursor was hidden, directScanoutTo was 0 and the stuttering/glitches stopped. When unhiding the cursor by going into a menu, directScanoutTo stayed as 0.

Yeah, just had some time to test too. Results came like this:

• There still seems to be some sort of inconsistency with DS, tearing, and hw cursor triggering at the same time. It's more apparent with animations disabled for some reason, but I often catch activelyTearing true but directScanoutTo 0.
• Moving hw cursor (cpu buffer) just kills DS for the rest of the time the game is fullscreened. Can sometimes be randomly recovered when flicking between workspaces or going between tiled / floating and fullscreen a few times.

@fxzzi
can you tell me what app/game you use see if there's tearing cause I can't seem to get it? although its possible my gpu is too op hehe
also what options do you use for,misc:vrr,render:direct_scanout,general:allow_tearing,cursor:no_hardware_cursors

btw if you test the new commits out, I changed the activelyTearing and directScanoutTo to be simpler for thehyprctl monitors command

edit:
I just realized the weird behavior probably has something to do with nvidia so I'll try my old 1660 card sometime soon

I just realized the weird behavior probably has something to do with nvidia

likely, tho i've also noticed some strange behaviour on my friends AMD based PC (not tested this PR there yet). On certain games for him (Minecraft 1.8.9, Paradox games like crusader kings 3, hearts of iron 4, etc), if he changes workspace and back to the game, his fps is locked to a low number (like 30 or so) for about 10-15 seconds. Also happens when notifications show on screen etc.

I tested a few combinations with him:

# broken, fps locked for about 10 secondshyprctl keyword render:direct_scanout 1hyprctl keyword general:allow_tearing 1hyprctl keyword misc:vrr 2

# also brokenhyprctl keyword render:direct_scanout 0hyprctl keyword general:allow_tearing 1hyprctl keyword misc:vrr 2

# works (and so does vrr 0)hyprctl keyword render:direct_scanout 0hyprctl keyword general:allow_tearing 0hyprctl keyword misc:vrr 2

I use the exact same setup with my nvidia GPU and don't experience this bug

can you tell me what app/game you use see if there's tearing cause I can't seem to get it?

I'm checking for tearing in a few games.

• Geometry Dash, which I run at double my monitor refresh rate experiences tearing as expected (340fps).
• Counter-Strike: Source, which I run at 3 below my refresh rate (167fps), theoretically shouldn't tear with vrr, tearing and ds all enabled at once, but still does. (i assume vrr should avoid tearing with tearing enabled, but without the latency increase of having tearing disabled)

EDIT: also maybe an nvidia related issue. Sometimes games feel stuttery and it magically fixes by going to a different TTY and back. idk y

cursor:no_hardware_cursors is false, using defaults for cursor stuff (cpu buffer on nvidia system, regular hw cursor on the amd sys)

vrr seems to be broken tho even if the cursor is invisible. Noticed this on ghost of tsushima. Controller works fine with VRR, but using my mouse causes my monitor OSD to stay at 170

ok so the main issue is that the kernel doesn't really like anything changing, including the hw cursor position, while doing a tearing page flip
so my workaround is to use a seperate commit which shouldn't trigger any page flip in order to update the hw cursor position
however, the kernel only seems to like updating the hw cursor at vsync framerate, so moving the cursor limits the frames and could cause temporary stuttering

I'll try asking around about tearing and hw cursor, hopefully there are some better workarounds or a kernel mechanism I missed, but this is the best we got for now

theoretically shouldn't tear with vrr, tearing and ds all enabled at once, but still does. (i assume vrr should avoid tearing with tearing enabled, but without the latency increase of having tearing disabled)

not sure if this is the expected the behavior but it's up to the kernel since all we have are switches for tearing and vrr

also maybe an nvidia related issue. Sometimes games feel stuttery and it magically fixes by going to a different TTY and back. idk y

its probably related to the workaround limiting frames

vrr seems to be broken tho even if the cursor is invisible.

this is probably related tocursor:no_break_fs_vrr as UjinT34 suspected, but either way fixing vrr is kinda out of scope for this pr

thanks for the explanation, seems the kernel has more to do with ds tearing and vrr than I expected.

fixing vrr is kinda out of scope for this pr

yeah, I know, just thought I'd share anyway since it seems to be an issue in relation to them. my apologies :)

I'm using an AMD gpu with Mesa git and Kernel 6.15.3. I have these tearing related settings:

general:allow_tearing 1render:direct_scanout 1misc:vrr 2

With the latest commits this PR doesn't cause stuttering or glitches, but still behaves a bit weirdly. When starting a game, tearing gets activated and scanout as well. However direct scanout keeps flipping between on and off unless I constantly move the mouse around. Also moving the mouse out of the game's monitor causes direct scanout to get stuck as off and it won't turn on when the cursor is back on the same monitor. Also it turns permanently off when the game hides the cursor (I was testing an FPS game).

tested your latest commits with hw cursor stuff disabled:

{programs.hyprland.settings={cursor={no_hardware_cursors=1;min_refresh_rate=32;no_break_fs_vrr=1;};};}

Still unable to get the two to activate at the same time reliably. The change in syntax for currentTearing and currentScanout also broke agsv1 for me, I think because of the space in the output:

(com.github.Aylur.ags:1582): Gjs-WARNING**: 02:36:20.202: JS ERROR: SyntaxError: JSON.parse: expected ',' or '}' after property value in object at line 28 column 29 of the JSON data @ resource:///com/github/Aylur/ags/service/hyprland.js:108:30Hyprland@resource:///com/github/Aylur/ags/service/hyprland.js:108:30@resource:///com/github/Aylur/ags/service/hyprland.js:334:25

edit: fwiw i think the false or true is useless, just show 0 / false if no window is actively being teared / ds'd, and then show the window id if there is. should avoid needing a space in the output

no_hardware_cursors = 1 disables DS. DS works when HL doesn't need to do anything with the rendered frame. SW cursors, monitor mirrors, screen capture, scaling, rotating and similar stuff will disable DS.

So from what I can understand this makes it impossible to tear and ds at the same time? And so this PR is not possible?

Because the Hyprland wiki shows disable hw cursors as 2 by default, which says

2 - auto (disable when tearing)

Or does "disable" here mean to disable no hw cursor, hence enabling it again?

It means "Disable HW cursors, when tearing"

Very confusing with the double negatives... Anyway

Yeah that does kinda of back up my point from what I can see.

Currently (outside of the scope of this PR), VRR is fundamentally broken with hw cursor. Invisible hw cursor moving even causes the refresh rate to jump up to max.

So we must use SW cursor, which then in turn stops DS from working, and tearing does work in both cursor modes from what I can see.

So it's not currently possible for all 3 to be active at the same time I guess.

edit: actually, figured it out.

{programs.hyprland.settings={cursor={no_hardware_cursors=0;min_refresh_rate=32;no_break_fs_vrr=1;};};}

seemed to work for me (my vrr range goes down to 32)

this works OK on latest git, but there seems to be a regression in this PR. When moving the camera with my mouse in minecraft, native wayland, monitor OSD reports half refresh rate. So the game feels choppy. This doesn't occur with latest git.

So from what I can understand this makes it impossible to tear and ds at the same time? And so this PR is not possible?

For now, yes
It's definitely physically possible, the kernel just hasn't implemented a way to do it yet (at least for atomic drm)

this works OK on latest git, but there seems to be a regression in this PR. When moving the camera with my mouse in minecraft, native wayland, monitor OSD reports half refresh rate. So the game feels choppy. This doesn't occur with latest git.

that's probably caused by the workaround I tried to make, which is wrong, in this PR

okie dokie, thank you for explaining.

well the PR does at least seem to fix my issue in#10880, but agsv1 is broken here and the mouse workaround is causing the above issue.

By any chance could the syntax of currentTearing and currentScanout be changed to remove the space, and the mouse workaround removed (since it didn't work anyway)? I wanted to test if this at least made the behaviour more correct than it was before, I feel it will 🙏🏽

@vaxerski
kernel devs talked about trying to fix tearing+hw cursor, but they said it didn't get anywhere then (https://patchwork.freedesktop.org/patch/243088). I'll keep reminding them though

but like@fxzzi said, this does fix some issues + cleans up related code so do you wanna merge those parts?
I will need to do some work to remove the workaround though, just asking if you're willing to merge the rest

edit:
I also found thishttps://lists.freedesktop.org/archives/dri-devel/2019-April/214291.html
which seems like a newer attempt, though it also fell through

Comments from 2018 :woe:

Anyway, since this PR has gone slightly off the rails lol I would like to also point out#10452, but idk if it's trivial to add or not

I am fine with the rest

@fxzzi test plz :)

edit:
also vaxry I made hw cursor always disable with tearing, since it just isn't possible for them to work together right now

@fxzzi test plz :)

Sorry 😔 won't be able to test for a few weeks as I'm on holiday

Hopefully someone else here is willing to test and we can get these changes into 0.50 :)

Tearing with this pr while using direct scanout appears to be working properly.