Bug 510892

Summary:	Compositing is still active even when the window is fullscreen
Product:	[Plasma] kwin	Reporter:	Andrew <kezin636>
Component:	compositing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	nate, xaver.hugl
Priority:	NOR	Keywords:	regression, wayland-only
Version First Reported In:	6.4.91
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Quick showcase of the bug

Description Andrew 2025-10-21 23:59:15 UTC

Whenever I try to play a game in fullscreen, there's a slight delay, even though, there's a rule for my game's window to allow tearing. I accessed the "Show Compositing" effect in KWin's debug console, activated it, and it showed me... "Compositing". Even in fullscreen mode without a mouse.

And no, picture-in-picture is not active. 

**STEPS TO REPRODUCE**
1. Enable tearing in fullscreen windows in Display Settings
2. Allow tearing for application window using Window Rules
3. Open KWin Debug console, activate `showcompositing` effect
4. Play any fullscreen game with or without cursor visible, doesn't matter

**OBSERVED RESULT**
"Compositing" label is still present

**EXPECTED RESULT**
No "Compositing" label on the screen

**SOFTWARE/OS VERSIONS**
Operating System: Arch Linux
KDE Plasma Version: 6.4.91
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.4-4-cachyos (64-bit) (they fixed the async flip issue before mainline)
Graphics Platform: Wayland
Processors: 6 × Intel® Core™ i5-8400 CPU @ 2.80GHz
Memory: 16 GiB of RAM (15.5 GiB usable)
Graphics Processor: NVIDIA GeForce GTX 1660 Ti (nvidia-open drivers)

**ADDITIONAL INFORMATION**
P.S. I also discovered some strange cursor behaviour when recording with GPU Screen Recorder (not using portal)

Comment 1 Andrew 2025-10-22 00:02:46 UTC

Created attachment 185980 [details]
Quick showcase of the bug

Comment 2 Zamundaaa 2025-10-22 19:58:56 UTC

Tearing and compositing are not related, and direct scanout is an optional optimization that simply does not work in all situations, with all graphics driver setups and display settings.
You can try to disable the color profile, HDR, night light and make sure you don't have any kwin effects active to make sure they're not interfering, but there's really no guarantee for it to work.

If you run vrrtest at some refresh rate lower than the screen refresh rate, and set the window rule to force tearing on it, do you see visible tearing in that case?

> P.S. I also discovered some strange cursor behaviour when recording with GPU Screen Recorder (not using portal)
kmsgrab is not and never will be supported. If you don't use the portal, there's literally nothing we can do about issues you have.

Comment 3 Andrew 2025-10-23 15:44:20 UTC

(In reply to Zamundaaa from comment #2)
> Tearing and compositing are not related, and direct scanout is an optional
> optimization that simply does not work in all situations, with all graphics
> driver setups and display settings.
> You can try to disable the color profile, HDR, night light and make sure you
> don't have any kwin effects active to make sure they're not interfering, but
> there's really no guarantee for it to work.
> 
> If you run vrrtest at some refresh rate lower than the screen refresh rate,
> and set the window rule to force tearing on it, do you see visible tearing
> in that case?
> 
> > P.S. I also discovered some strange cursor behaviour when recording with GPU Screen Recorder (not using portal)
> kmsgrab is not and never will be supported. If you don't use the portal,
> there's literally nothing we can do about issues you have.

Ran vrrtest, seems ok, tearing is there. Thanks for the VRR testing software advice tho, really appreciate that.
Maybe I'm just panicking or making myself thinking something is wrong. Sorry for false reporting this.