Bug 498181

Summary: Unable to disable compositor-provided Vsync globally on Wayland
Product: [Plasma] kwin Reporter: Gemskip <cornerboost>
Component: wayland-genericAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED NOT A BUG    
Severity: wishlist CC: cornerboost, kde
Priority: NOR    
Version First Reported In: 6.2.5   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Gemskip 2025-01-02 20:09:50 UTC 
Not sure if feature requests are allowed here, and I'm getting mixed messages on whether they are, so I'm adding this as wishlist severity since this counts as a Wayland showstopper/feature parity issue for me. Feel free to take it down.

On X11, it is possible to bypass compositor-enforced Vsync by disabling the compositor entirely. This is currently how I use my systems, because it is noticeably more responsive than letting it wait for Vsync on either composited session. This causes the screen to "tear", which I do not mind. There is currently no alternative to doing this on the Wayland session, outside of the fullscreen gaming usecase. 

It is important that the user can opt into tearing across the desktop, so that applications besides fullscreen games (such as windowed games, drawing software, and general usage) can retain responsive behavior in the absence of a specialized high-refresh rate monitor.
Comment 1 David Edmundson 2025-01-03 10:42:37 UTC 
>This is currently how I use my systems, because it is noticeably more responsive than letting it wait for Vsync on either composited session

Blindly copying what might have improved performance on X11 into a wayland session isn't the right approach. Kwin not vsyncing whilst clients are waiting on frame callbacks anyway would achieve absolutely nothing especially for non-gaming apps, it's important to take the whole stack into account.

We will continue to improve performance, but that means different fixes.
Comment 2 Gemskip 2025-01-03 18:54:29 UTC 
> Blindly copying what might have improved performance on X11 into a wayland
> session isn't the right approach.

I'm referring to input latency and not general performance. Not waiting for Vsync probably takes more system resources in general even though it is more responsive. Waiting for Vsync causing latency is pretty universal across operating systems, it is simply disregarded as tearing is less desirable than ~16ms delay for most users.

>Kwin not Vsyncing while clients are waiting for frame callbacks would achieve absolutely nothing anyway.
I am not sure how it is implemented, but another Wayland compositor has a forced tearing PR in the works that definitely does improve input responsiveness on 60hz displays and works in windowed applications. The "allow tearing" option in fullscreen games on Kwin achieves a similar improvement in input delay that feels in line with X11. I don't know if this means the compositor is spamming the client with frame callbacks or what, but it feels identical to uncomposited Xorg and very smooth whereas non-tearing situations feel like I am using my computer underwater.

>Especially for non-gaming apps.
The difference is the same for gaming and non-gaming apps. Gamers speak up about it because for their use case it is unacceptable.