Framerates are locked to refresh rate

[Stoppedpuma]

Regression?

Yes

System Info and Version

System/Version info

Hyprland, built from branch main at commit e2efecc (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

[vaxerski]

thats how it's always been, welcome to wayland

[Stoppedpuma]

I'm aware that's how wayland is designed but in specific applications (mostly games) framerates could go above the refresh rate in both wayland and xwayland modes. This still works fine in commits prior to aq as well as other wayland compositors such as sway.

VIsual of this working fine in sway:

Visual of this not working in Hyprland e2efecc:

[vaxerski]

it's up to the app not hyprland, though.

[Stoppedpuma]

it's up to the app not hyprland, though.

This behaviour works fine prior to the aq merge in Hyprland as well as other wayland compositors, shouldn't this be re-opened since this is a bug on master?

[vaxerski]

still not convinced. What's the test client?

[Stoppedpuma]

Easy to reproduce with osu! as basically any modern hardware will run the game at 1000fps, launch option is SDL_VIDEODRIVER=wayland /path/to/osu.AppImage. This behaviour is reproducible in anything that is wayland native, xwayland works fine.

Hyprland v0.41.2 and sway 1.9 both work fine, Hyprland master does not.

[a-usr]

Why would you want the fps to be higher than the refresh rate anyways? Is there any use even if the monitor cant/wont keep up? Also can you confirm that sway is not just detecting and using a 1000hz refresh rate for your monitor, whereas hyprland uses 240hz?

[vaxerski]

there is a benefit in reduced latency

[a-usr]

there is a benefit in reduced latency

I always thought that capping the fps at a lower value would lower the latency since the game engine needs to spend less time on computing the frames and has more time for processing input

or are you not talking about input latency

[vaxerski]

input latency

[a-usr]

ok

[RafGamer]

I have the exact same problem. Switched from 0.41.2 to hyprland-git e673220 to try and see if it fixes #6230.
It did but now the fps are locked to the refresh rate.
When setting allow_tearing = false it works normally and the fps are unlocked.
Seems like its an issue with tearing.
The game I tried is CS2.

[Stoppedpuma]

Can confirm, this seems to only happen when tearing is enabled.

[Stoppedpuma]

This was kind of fixed? The problem still exists sometimes after tabbing into another application and back sometimes though.

[RafGamer]

This was kind of fixed? The problem still exists sometimes after tabbing into another application and back sometimes though.

It still doesn't work for me. The fps are unlocked when activelyTearing is false and are locked to the refresh rate when its true. Shouldn't it be the exact opposite?

[Stoppedpuma]

It should be unlimited either way. No clue why tearing is the thing breaking this though. Also it seems you're correct, it does still break when tearing. For some reason tearing is completely broken now and decides not to work until re-tabbing in and out several times.

[RafGamer]

It should be unlimited either way.

I thought it should be locked when tearing is off. Isn't that the default behavior of wayland like vaxry said in the first comment?

For some reason tearing is completely broken now and decides not to work until re-tabbing in and out several times.

This doesn't work for me either.

With wayland windows, tearing doesn't activate and the fps are unlocked. When the window is a xwayland client, tearing activates and the fps are locked. That is how it is for me.

Maybe these are two different problems. I don't know.

[Stoppedpuma]

I thought it should be locked when tearing is off. Isn't that the default behavior of wayland like vaxry said in the first comment?

Unless vaxry feels the want to break consistency with every other wayland compositor, no. The framerate should be uncapped in either scenario.

Maybe these are two different problems. I don't know.

No clue either at this point, these commits need to be tested a lot more it seems as things as critical as the displays only rendering a black screen is apparently being unnoticed until it's merged somehow.

[vaxerski]

you can only blame yourself for not testing MRs for that. Everyone who was active in testing new changes reported having no issues.

[Stoppedpuma]

While that may be true, you still decided to rush the merge causing issues here. Additionally, some of the issues that were reported and you didn't fix prior to merging, an example being the frame pacing issues. A PR as large as aq I feel should have probably been delayed a bit longer. While I won't tell you how to run your project, I will point out that from a users perspective it's rather unpleasant having changes constantly break something because they weren't tested well enough, this is especially the case with the issue mentioned above with the display rendering a black screen at some point.

Please @ me when you have a proposed fix / PR ready for this issue so I can test. Thanks!

[vaxerski]

that's what a -git version is for. The critical issues that arose from the MR are blockers for 0.42.

This isn't, because tearing has always been wonky and experimental.

[RafGamer]

I did some more testing.
The problem seems to be with xwayland. With xwayland clients and tearing enabled, the fps are always locked to the refresh rate.
I tried using vkcube-wayland, which spawns a wayland client. Enabled tearing and the fps were more than the refresh rate.
Now to my second problem, which I described above, that tearing doesn't seem to activate when using wayland clients.
The problem is that when using gamescope, hyprctl clients reports the wrong client. It shows the gamescope program, not the game running inside gamescope. I think that's the reason tearing doesn't activate.
When the game is a xwayland client it works and by comparing the reported pid with something like btop I can clearly see that its the game and not gamescope.
Did I do something wrong with my configuration or should I open a new issue because its a bug?

[a-usr]

The problem is that when using gamescope, hyprctl clients reports the wrong client. It shows the gamescope program, not the game running inside gamescope.

Thats because XWayland afaik directly interops with the compositor (Hyprland), while gamescope doesn't. Gamescope is a microcompositor. It can run as a wayland client, or directly use the DRM if you start it from the tty. When it is run as a wayland client it renders its own clients on its wayland surface (Inside of its Window), just like what Hyprland does when you run Hyprland as a wayland client. A client running in gamescope belongs to gamescope, not Hyprland. As for tearing not activating in gamescope, Hyprland doesn't manage Tearing inside of gamescope.

[RafGamer]

Thats because XWayland afaik directly interops with the compositor (Hyprland), while gamescope doesn't.

It doesnt matter if the game is run with gamescope or without. The client shown by hyprctl clients is always the correct game client when its xwayland.

But when the game is wayland it shows always the gamescope compositor.

As for tearing not activating in gamescope, Hyprland doesn't manage Tearing inside of gamescope.

That means I dont have to mess with hyprlands tearing settings at all when running nested gamescope?

[a-usr]

But when the game is wayland it shows always the gamescope compositor.

You mean even if it isnt running within gamescope? That shouldn't be the case...

That means I dont have to mess with hyprlands tearing settings at all when running nested gamescope?

Well, If tearing is disabled Hyprland will limit the fps at which gamescope renders, but if gamescope limits the fps of its own clients by itself already the tearing setting in Hyprland wont help. You have to make sure that Tearing is enabled both in Hyprland and in gamescope ( If there is even an option for that )

It might be helpful to know what distro you use

[Stoppedpuma]

I did some more testing.
The problem seems to be with xwayland. With xwayland clients and tearing enabled, the fps are always locked to the refresh rate.

Odd, I'm experiencing the exact opposite behaviour where wayland windows are the ones causing problems with tearing. Can you make sure with hyprctl clients that your game is tearing properly because a change along the way seems to have broken wayland clients being able to tear correctly sometimes. Additionally testing without gamescope would be nice here.

[vaxerski]

have yall tried aq-git

[RafGamer]

gamescope + wayland client inside --> hyprctl clients shows wrong pid, cant activate tearing, fps unlocked

wayland client without gamescope --> hyprctl clients shows correct pid, tearing activates, fps unlocked

gamescope + xwayland client --> hyprctl clients shows wrong pid, cant activate tearing, fps unlocked

xwayland client without gamescope --> hyprctl clients shows correct pid, tearing activates, fps locked

Tested with glxgears for xwayland and vkcube-wayland for wayland.

For some reason when running cs2 with gamescope it behaves like this:

gamescope + xwayland client --> hyprctl clients shows correct pid, tearing activates, fps locked

This is really confusing at this point.

You have to make sure that Tearing is enabled both in Hyprland and in gamescope ( If there is even an option for that )

There is --immediate-flips but its only for embedded mode. Couldnt find anything else. Seems like tearing cant be activated in gamescope when running nested mode.

It might be helpful to know what distro you use

Arch

[a-usr]

Yeah when you run a client nested inside of gamescope that client registers to gamescope, not hyprland, and gamescope in turn registers itself to hyprland. As far as the client running inside of gamescope is concerned there is nothing beyond gamescope. The PID belonging to the gamescope process isn't wrong.

About cs2, are you sure that it's running with gamescope? Do you have gamescope in the Steam launch args? Because if not it should create an xwayland client.

gamescope + wayland client inside --> hyprctl clients shows wrong pid, cant activate tearing, fps unlocked

wayland client without gamescope --> hyprctl clients shows correct pid, tearing activates, fps unlocked

gamescope + xwayland client --> hyprctl clients shows wrong pid, cant activate tearing, fps unlocked

xwayland client without gamescope --> hyprctl clients shows correct pid, tearing activates, fps locked

xwayland does seem to affect the FPS at which the client can render stuff.
Also, when the clients run in gamescope, they may seem to have high fps, but the actual rate at which the frames get drawn to the screen can still be limited by Hyprland, and the client inside of gamescope won't ever learn of that.

[RafGamer]

About cs2, are you sure that it's running with gamescope? Do you have gamescope in the Steam launch args? Because if not it should create an xwayland client.

Yes I have the correct steam launch args.

Did some more testing and hyprctl clients only shows the "real" game client when the game inside gamescope is a xwayland client.

Only when running games with proton-ge, which afaik uses wayland instead of xwayland, hyprctl clients shows the gamescope pid.

[a-usr]

Did some more testing and hyprctl clients only shows the "real" game client when the game inside gamescope is a xwayland client.

Only when running games with proton-ge, which afaik uses wayland instead of xwayland, hyprctl clients shows the gamescope pid.

???? this doesn't make much sense to me

[RafGamer]

???? this doesn't make much sense to me

It only does that when I launch it through steam.
Outside of steam it behaves like I explained in the comment above.

One thing I didn't mention is that I am using the flatpak version of steam. Maybe the flatpak version of gamescope works differently.
But I did use the native installed version of gamescope for the tests I did with glxgears and vkcube-wayland.

[a-usr]

No you see, as far as I understand the PID that hyprctl clients reports belongs to the process that requested the wayland surface thats being rendered to. So a surface that belongs to gamescope should have an associated pid that belongs to gamescope. And since a X11 client doesnt speak wayland it also shouldnt have a non-xwayland surface associated with it. Thats my main issue here.

[RafGamer]

No you see, as far as I understand the PID that hyprctl clients reports belongs to the process that requested the wayland surface thats being rendered to. So a surface that belongs to gamescope should have an associated pid that belongs to gamescope. And since a X11 client doesnt speak wayland it also shouldnt have a non-xwayland surface associated with it. Thats my main issue here.

Yes I understand.

When running with Proton Experimental hyprctl clients shows the following:
class: steam_app_671860

With Proton-GE:
class: gamescope

It also throws this error with Proton Experimental:
CreateSwapchainKHR: Creating swapchain for non-Gamescope swapchain. Hooking has failed somewhere! You may have a bad Vulkan layer interfering. Press OK to try to power through this error, or Cancel to stop.

But after clicking OK two times the game launches.

It seems like it doesnt really start through gamescope when using something other than Proton-GE.
Both times with the same steam game launch args.

[a-usr]

It seems like it doesnt really start through gamescope when using something other than Proton-GE. Both times with the same steam game launch args.

You could try checking wether gamescope runs at all when starting without proton-ge / with proton experimental. Just to verify. However that would definetly explain the pid thing.

[RafGamer]

You could try checking wether gamescope runs at all when starting without proton-ge / with proton experimental. Just to verify. However that would definetly explain the pid thing.

Yes I can see a gamescope process.

[a-usr]

Yes I can see a gamescope process.

In that case it seems like gamescope is no-scoping

I seriously need to learn how to make good jokes

[a-usr]

Wait but is the window that gets created an xwayland window ?

[RafGamer]

Wait but is the window that gets created an xwayland window ?

Yes, xwayland: 1. Like I said it doesnt run in gamescope and it does that only when running something with gamescope through steam and using something other than Proton-GE.

Its pretty clear that this is another issue and that something is wrong with gamescope. I dont know but I think that hyprland has nothing to do with this issue.

But I now I dont understand why someone should run games with nested gamescope when it doesnt even support tearing in nested mode. And its causing more problems than it solves.

But the other problem still persists. With xwayland windows and tearing enabled the fps is locking to the refresh rate. I think we should focus on that because that seems like its an issue with hyprland.

Also this:

Only when running games with proton-ge, which afaik uses wayland instead of xwayland

Doesnt seem to be correct, because when running the game through proton-ge and without gamescope it still spawns a xwayland client.

[a-usr]

This is probably relevant:

Please note that tearing will only be in effect when the game is in fullscreen and [ /or ] the only thing visible on the screen.

And apart from that it seems hyprland never tells xwayland to start tearing

[RafGamer]

I tried looking at the logs and this is what gets spammed:
[ERR] [AQ] atomic drm request: failed to commit: Invalid argument, flags: ATOMIC_NONBLOCK PAGE_FLIP_ASYNC

When setting env = AQ_NO_ATOMIC,1 (i know its not recommended) the fps are unlocked with tearing enabled. But it produces a lot of bugs like screen artifacts (as expected).

[a-usr]

I tried looking at the logs and this is what gets spammed: [ERR] [AQ] atomic drm request: failed to commit: Invalid argument, flags: ATOMIC_NONBLOCK PAGE_FLIP_ASYNC

I have been seeing those in my own logs too.

[RafGamer]

After updating my system and hyprland-git and all of the dependencies the fps are only locked while moving the mouse.

[Stoppedpuma]

After updating my system and hyprland-git and all of the dependencies the fps are only locked while moving the mouse.

Which application are you seeing this behaviour in? Framerates are still locked completely on my end with the applications I've tested.

[RafGamer]

Which application are you seeing this behaviour in? Framerates are still locked completely on my end with the applications I've tested.

glxgears and also games like cs2.

[Stoppedpuma]

I can't seem to reproduce on either. Are you sure the application is still tearing while your mouse isn't moving?

[RafGamer]

I can't seem to reproduce on either. Are you sure the application is still tearing while your mouse isn't moving?

hyprctl monitors shows that its tearing no matter if I move my mouse or not.

[RafGamer]

Everything is working fine when setting no_hardware_cursors = true.
Maybe this explains it: #7453 (comment)

[a-usr]

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

[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.