Framerates are locked to refresh rate

[Stoppedpuma]

Regression?

Yes

System Info and Version

System/Version info

Hyprland, built from branch main at commit e2efecc24e6534f46352cab13975778e3f0b5735 (flake: update aquamarine). Date: Wed Jul 24 00:42:15 2024 Tag: v0.41.2-82-ge2efecc2, commits: 4968 flags: (if any) System Information: System name: Linux Release: 6.8.9-273-tkg-eevdf-llvm Version: #1 SMP PREEMPT_DYNAMIC TKG Sat, 11 May 2024 06:09:58 +0000 GPU information: 0c: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 c5) (prog-if 00 [VGA controller])

Description

Framerates are locked at the displays refresh rate. Going to assume this is caused by aq merge.

How to reproduce

May require tearing to be enabled, I haven't tested.

Crash reports, logs, images, videos

No response

[RafGamer]

Funky. In that case I suppose the issue is resolved?

Depends on what the author of this issue has to say. Also, like the comment I linked says, I dont know if this is something that can be fixed in hyprland or if it is entirely a kernel issue.

[Stoppedpuma]

This issue should likely remain opened until it's solved upstream, be it on the kernel or Hyprlands side.

@RafGamer If you're willing to build a kernel with that commit and test against Hyprland master that would be helpful to know if this is an issue on Hyprlands side or not as Sway doesn't seem to have this issue but depends on similar patches.

[a-usr]

I mean, I suppose Hyprland/Aquamarine could just spawn a second thread, which dispatches the page-flips synchronously, but I feel like that would be error-prone and a waste of resources

[RafGamer]

@RafGamer If you're willing to build a kernel with that commit and test against Hyprland master that would be helpful to know if this is an issue on Hyprlands side or not as Sway doesn't seem to have this issue but depends on similar patches.

Even if it works, there are other compositors that don't have this problem and they also don't depend on any kernel patches. So there has to be a way to fix this. Also, @Stoppedpuma, can you test if the problem still occurs when disabling the hardware cursor?

[Stoppedpuma]

Even if it works, there are other compositors that don't have this problem and they also don't depend on any kernel patches. So there has to be a way to fix this.

Not sure about this, wlroots compositors require a similar patch for tearing to work without no_atomic so there's probably an additional patch on the few compositors that do work correctly without kernel side patches.

Also, @Stoppedpuma, can you test if the problem still occurs when disabling the hardware cursor?

Regardless of if this works around the issue or not it's not necessarily a fix, similar to how no_atomic works around the issue, it's more a hacky workaround.

[RafGamer]

Not sure about this, wlroots compositors require a similar patch for tearing to work without no_atomic so there's probably an additional patch on the few compositors that do work correctly without kernel side patches.

Yeah, I researched it and it seems your right. They all have some sort of problem with tearing and atomic.

Regardless of if this works around the issue or not it's not necessarily a fix, similar to how no_atomic works around the issue, it's more a hacky workaround.

Yeah I know, I just wanted to see if the cause of the problem is the same in your case.

Also, I dont really know which patches I need, because it seems like some were already merged.

EDIT:

I found this: https://invent.kde.org/plasma/kwin/-/merge_requests/4800.

So does that mean it works in KWin and all the required patches are already merged? Now I'm really confused.

[Stoppedpuma]

That might be a patch on the compositors end? Tearing used to work on Hyprland prior to the aq merge so I'm assuming something similar was done on Hyprlands end as well? Regardless, it would be an incorrect approach to apply a "workaround" instead of just waiting for proper support from the kernels side as it's already in development and should be merged sooner or later.

[RafGamer]

That might be a patch on the compositors end? Tearing used to work on Hyprland prior to the aq merge so I'm assuming something similar was done on Hyprlands end as well? Regardless, it would be an incorrect approach to apply a "workaround" instead of just waiting for proper support from the kernels side as it's already in development and should be merged sooner or later.

Yeah, I didn't look closely enough. Seems like the merge request also automatically disables the hardware cursor when tearing is active. And yes I agree, we should wait for proper support from the kernels side. I just hope that someone is working on that.