Bug 510967

Update: It seems to be related to Vsync, as I always have it off on these games and enabling it fixes it

What kernel version are you on?

(In reply to Zamundaaa from comment #2)
> What kernel version are you on?

Kernel 6.17.4 - arch
I'm forcing tearing with MESA_VK_WSI_PRESENT_MODE=immediate or d3d9.presentInterval = 0 (in L4D2)
With this, ds worked in 6.4.5 while ingame in both games but not while in menus

With kwin 6.5.0 with the patches it works fine when enabling vsync

Direct Scanout never worked as expected for me. Interestingly, I noticed the issue doesn't affect OpenGL. Whether vsync is enabled or not, glxgear always have direct scanout. The issues mostly affect Vulkan.

Here are some observations:

KWin 6.4
Glxgears - no issues
Vkcube - mostly working, but if you press Meta key twice it might get buggy: https://www.youtube.com/watch?v=NNMd9zEBxJQ
World of Warcraft (protonGE) - working only when you move camera: https://www.youtube.com/watch?v=JQ8F1V_Ly2c

KWin 6.5
Glxgears - no issues
Vkcube - same as before, but need to enable vsync
World of Warcraft (protonGE) - not working at all regardless vsync is enabled or not

Forgot to note I am using 6.17.4-arch/amdgpu RX 6900 XT/wayland

Just compiled kwin from Plasma/6.5 branch (4526fe9ee34c4a8a47ebf00046361d4913ad106):
- direct scanout works with MAILBOX and FIFO present modes [OK - already fixed on GIT]
- direct scanout stops working with MAILBOX and FIFO present modes for a moment when mouse cursor appears and soon later it works again, I can see that "compositing" red text appears for a moment - e.g. press ESC in game to open menu which shows cursor [still regression 6.4.5 -> 6.5.0-git]
- direst scanout doesn't work with IMMEDIATE present mode when cursor is invisible [still regression 6.4.5 -> 6.5.0-git]
- direst scanout doesn't work with IMMEDIATE present mode when cursor is visible [it never worked IIRC - is it possible to fix it?]

Tested on QMPlay2 video player (Vulkan as subsurface) and one XWayland game.

> World of Warcraft (protonGE) - working only when you move camera: https://www.youtube.com/watch?v=JQ8F1V_Ly2c

Do you have v-sync off? If yes, it should be the issue I mentioned as "it never worked (...)".

> Do you have v-sync off? If yes, it should be the issue I mentioned as "it never worked (...)".
Yes, vsync is off. I think that's exactly what you are talking about. Direct scanout doesn't work when cursor is visible and vsync is off.

That video was recorded with KWin 6.4. However, in KWin 6.5 direct scanout in WoW not working at all regardless vsync is enabled or not.

But I found a better way to force vsync. If I create window rule and set "Allow tearing" to Off then direct scanout start working, however with some glitches. When I stop moving camera and release mouse button, you can see a short flash of "Compositing" text. Also look at the frametime spike: https://www.youtube.com/watch?v=GY_5oT8MFNY

> you can see a short flash of "Compositing" text

Yes, I also noticed it with v-sync enabled (see 2nd point).

> Also look at the frametime spike: https://www.youtube.com/watch?v=GY_5oT8MFNY

I think it's normal when compositing toggles (it should not toggle). It's nothing, I remember years ago Nvidia on Xorg (when Vulkan was new) - entire PC hanged for longer while or forever when compositing was toggled by fullscreen Vulkan app.

> you can see a short flash of "Compositing" text

In my case, the `child->boundingRect()` contains `QRectF(-4,-4 32x32)` for a single frame, that's why it enables/disables compositing when cursor appears.

(In reply to Błażej Szczygieł from comment #6)
> - direct scanout stops working with MAILBOX and FIFO present modes for a
> moment when mouse cursor appears and soon later it works again, I can see
> that "compositing" red text appears for a moment - e.g. press ESC in game to
> open menu which shows cursor [still regression 6.4.5 -> 6.5.0-git]
That's caused by the direct scanout candidate search checking if the cursor needs rendering, but the cursor needs rendering until Compositor::composite puts it on a plane - which only happens after the direct scanout candidate search.
I have some patches that will fix it, for Plasma 6.6. I think it was part of https://invent.kde.org/plasma/kwin/-/merge_requests/8076, though there might be more to it in a local branch. Something to look at once we can do more breaking changes without making backporting of bugfixes more difficult.

> - direst scanout doesn't work with IMMEDIATE present mode when cursor is
> invisible [still regression 6.4.5 -> 6.5.0-git]
Can confirm, though atm I can't explain why it doesn't work.

> - direst scanout doesn't work with IMMEDIATE present mode when cursor is
> visible [it never worked IIRC - is it possible to fix it?]
It's not really possible with current KMS API; there were some attempts to improve that situation, but I don't think

Oops, pressed the button too soon. I meant to write "I don't think anyone's working on it anymore"

Sorry for off topic, but how do you think, how much latency increase in situations (assuming I have VRR):
1) no vsync/direct scanout
2) no vsync/no direct scanout
3) vsync/direct scanout
4) vsync/no direct scanout

I'm trying to figure out what the best solution would be for me while wait for bug to be fixed. Staying on 6.4 or if the benefit is too small, just update to 6.5

Ok, thanks for explanation.

> It's not really possible with current KMS API; there were some attempts to improve that situation, but I don't think anyone's working on it anymore

Do you mean that no one in the kernel is working on it?

Is it theoretically possible to use direct scanout with night light or color profile (set to performance mode)?

In case it helps, 6.5.0 -> 6.5.1 did fix direct scanout for the moonlight-qt streaming client, but another open source application that still exhibits direct scanout issues in 6.5.1 is Firefox in native wayland mode (but xwayland mode seems to work OK).

Prerequisites:
* Enable showcompositing plugin in KWin
* In Firefox, ensure widget.wayland.fractional-scale.enabled is set to true via about:config (normally needed for direct scanout to work if fractional scaling is set by the system), otherwise all other config is set to default.

Procedure:
Test1: MOZ_ENABLE_WAYLAND=0 firefox https://www.google.com -> enter fullscreen via F11 and wait for cursor to settle.
Test2: MOZ_ENABLE_WAYLAND=1 firefox https://www.google.com -> enter fullscreen via F11 and wait for cursor to settle.
Test3: chromium https://www.google.com -> enter fullscreen via F11 and wait for fullscreen notification to disappear.

Results:
Test1: direct scanout works
Test2: direct scanout does not work
Test3: direct scanout works (same for other chromium-based browsers such as Chrome and Brave)

I believe that direct scanout was working fine in all of the above test cases in Plasma 6.4.5 (as seen in the Fedora 43 KDE live iso, for example).

> but another open source application that still exhibits direct scanout issues in 6.5.1 is Firefox in native wayland mode (but xwayland mode seems to work OK).

Firefox fails, because of `checkForBlackBackground()` function, the condition: `background->buffer()->size() != QSize(1, 1)` fails, because in my case it's `3840x2160`. When I remove this check, it's working fine. I don't know the idea of this function - @Zamundaaa could you look at this?

> direst scanout doesn't work with IMMEDIATE present mode when cursor is invisible

Reversed condition, I'll make MR for this.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8346

(In reply to Błażej Szczygieł from comment #17)
> Firefox fails, because of `checkForBlackBackground()` function, the
> condition: `background->buffer()->size() != QSize(1, 1)` fails, because in
> my case it's `3840x2160`. When I remove this check, it's working fine. I
> don't know the idea of this function - @Zamundaaa could you look at this?
It's there to efficiently check whether or not the background is completely black. Obviously, checking 8294400 pixels each frame would be much worse than compositing. This check works for mpv, which efficiently uses a single pixel buffer for the background.

FWIW Firefox on my system does get direct scanout in YouTube videos nowadays, while I hit the same issue in the past. There may be differences depending on the config and version.

(In reply to Zamundaaa from comment #19)
> (In reply to Błażej Szczygieł from comment #17)
> > Firefox fails, because of `checkForBlackBackground()` function, the
> > condition: `background->buffer()->size() != QSize(1, 1)` fails, because in
> > my case it's `3840x2160`. When I remove this check, it's working fine. I
> > don't know the idea of this function - @Zamundaaa could you look at this?
> It's there to efficiently check whether or not the background is completely
> black. Obviously, checking 8294400 pixels each frame would be much worse
> than compositing. This check works for mpv, which efficiently uses a single
> pixel buffer for the background.
> 
> FWIW Firefox on my system does get direct scanout in YouTube videos
> nowadays, while I hit the same issue in the past. There may be differences
> depending on the config and version.

Ok, but where we can see the background if Firefox covers entire screen (both "scanoutCandidates" has the same size)?

For me HW overlay is working for Firefox (Compositing text is covered), but making it fullscreen the Compositing text is visible because of this, hmm.

(In reply to Błażej Szczygieł from comment #20)
> Ok, but where we can see the background if Firefox covers entire screen
> (both "scanoutCandidates" has the same size)?
The background is a subsurface. You can't actually see it, but Firefox is misreporting the opaque region of the video, so KWin doesn't know it can ignore the subsurface (or at least that was the issue when I last had it).

> For me HW overlay is working for Firefox (Compositing text is covered), but
> making it fullscreen the Compositing text is visible because of this, hmm.
Using multiple planes for fullscreen won't always work right now. https://invent.kde.org/plasma/kwin/-/merge_requests/8076 will fix that.

Git commit 62d81edf4073131003e02756cce2b5c7cbdd58fb by Błażej Szczygieł.
Committed on 31/10/2025 at 22:05.
Pushed by zamundaaa into branch 'master'.

backends/drm: fix async present with direct scanout

M  +1    -1    src/backends/drm/drm_egl_layer.cpp

https://invent.kde.org/plasma/kwin/-/commit/62d81edf4073131003e02756cce2b5c7cbdd58fb

> The background is a subsurface. You can't actually see it, but Firefox is misreporting the opaque region of the video, so KWin doesn't know it can ignore the subsurface (or at least that was the issue when I last had it).

I'm sure it worked a while ago (now doesn't on 6.4.5 and 6.5.1). I noticed FF reports opaque region as 1920x1080 (scaling 200%, WAYLAND_DEBUG=1).

These are opaque regions for Firefox (1024x768 logical kwin size):
- QRegion(0,0 1024x747)
- QRegion(0,0 1024x768)
They indeed don't match, that's why kwin tries to check for background color. Could it be a Firefox bug or there's another weird unhandled logic there?

---

Question about direct scanout with ICC or Night Light - I can see in code that direct scanout is allowed in this case (color performance mode), but this fails in "prepareAtomicPresentation": "differentPipelines" is set (when I ignore it, no color profile is applied obviously). Is it possible somehow to use DS with ICC/Night Light?

I tested World of Warcraft with KWin 6.5.1 and noticed that if you have Battle.net Launcher opened, Direct Scanout stop working completely even for glxgear/chromium/other apps that was previously working with 6.5.0 and 95e7952f. if you exit Battle.net Launcher, then direct scanout works again.

Tested https://invent.kde.org/plasma/kwin/-/merge_requests/8346. I didn't notice any effect in WoW. Should it fix direct scanout with IMMEDIATE or MAILBOX short flash of "Compositing" text when release mouse?

> Should it fix direct scanout with IMMEDIATE or MAILBOX short flash of "Compositing" text when release mouse?

No, it fixes IMMEDIATE present mode when mouse cursor is hidden. Short flash of "Compositing" is not yet fixed and it has been explained here: https://bugs.kde.org/show_bug.cgi?id=510967#c11

> if you have Battle.net Launcher opened, Direct Scanout stop working completely

Does it work in 6.4.5? Maybe Battle.net it shows an invisible overlay window somewhere? Is it wine-wayland or XWayland?

---

Btw. tested this: https://invent.kde.org/plasma/kwin/-/merge_requests/8343 - it hangs on fullscreen with IMMEDIATE mode (also without direct scanout).

> > Should it fix direct scanout with IMMEDIATE or MAILBOX short flash of "Compositing" text when release mouse?
> 
> No, it fixes IMMEDIATE present mode when mouse cursor is hidden. Short flash
> of "Compositing" is not yet fixed and it has been explained here:
> https://bugs.kde.org/show_bug.cgi?id=510967#c11
For me it still has no effect on IMMEDIATE present mode when mouse cursor is hidden (at least in WoW, didn't checked other games)

> > if you have Battle.net Launcher opened, Direct Scanout stop working completely
> 
> Does it work in 6.4.5? Maybe Battle.net it shows an invisible overlay window
> somewhere? Is it wine-wayland or XWayland?
Yes, it was working in 6.4.5 with FIFO/MAILBOX and IMMEDIATE when cursor is hidded. It's XWayland. Battle.net never work in pure Wayland

Sorry, ignore what I have said about https://invent.kde.org/plasma/kwin/-/merge_requests/8346. I recompiled KWin and patch works correctly.

Current state:
- direct scanout works with MAILBOX and FIFO present modes [OK - already fixed on GIT]
- direct scanout stops working with MAILBOX and FIFO present modes for a moment when mouse cursor appears and soon later it works again, I can see that "compositing" red text appears for a moment - e.g. press ESC in game to open menu which shows cursor [still regression 6.4.5 -> 6.5.0-git]
- direst scanout doesn't work with IMMEDIATE present mode when cursor is invisible [OK - fixed with MR 8346]
- direst scanout doesn't work with IMMEDIATE present mode when cursor is visible [it never worked IIRC - is it possible to fix it?]
- direst scanout doesn't work if you have Battle.net Launcher opened [regression 6.5.0 > 6.5.1] I made video to better see the issue https://youtu.be/Ejs6mu2x7r0

fixed a typo

Current state:
- direct scanout works with MAILBOX and FIFO present modes [OK - already fixed on GIT]
- direct scanout stops working with MAILBOX and FIFO present modes for a moment when mouse cursor appears and soon later it works again, I can see that "compositing" red text appears for a moment - e.g. press ESC in game to open menu which shows cursor [still regression 6.4.5 -> 6.5.0-git]
- direst scanout works with IMMEDIATE present mode when cursor is invisible [OK - fixed with MR 8346]
- direst scanout doesn't work with IMMEDIATE present mode when cursor is visible [it never worked IIRC - is it possible to fix it?]
- direst scanout doesn't work if you have Battle.net Launcher opened [regression 6.5.0 > 6.5.1] I made video to better see the issue https://youtu.be/Ejs6mu2x7r0

(In reply to username from comment #28)
> - direst scanout doesn't work with IMMEDIATE present mode when cursor is
> visible [it never worked IIRC - is it possible to fix it?]
Not possible to fix on our side. On some hardware at least it's possible to fix in the kernel.

> - direst scanout doesn't work if you have Battle.net Launcher opened
> [regression 6.5.0 > 6.5.1] I made video to better see the issue
> https://youtu.be/Ejs6mu2x7r0
Please use the kwin debug console (search for it in krunner) to check what windows the launcher has. We had a similar issue with some launchers in the past, triggered by their system tray icons.

(In reply to Zamundaaa from comment #29)
> (In reply to username from comment #28)
> > - direst scanout doesn't work if you have Battle.net Launcher opened
> > [regression 6.5.0 > 6.5.1] I made video to better see the issue
> > https://youtu.be/Ejs6mu2x7r0
> Please use the kwin debug console (search for it in krunner) to check what
> windows the launcher has. We had a similar issue with some launchers in the
> past, triggered by their system tray icons.
I couldn't figure out how to copy text from the debug console, so here are the screenshots. There's one X11 Unmanaged Window that belongs to Battle.net https://imgur.com/a/XHI5q5G

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8389

Git commit 5462921f224c1ec7a597129f416e0feae11ce25c by Xaver Hugl.
Committed on 08/11/2025 at 16:13.
Pushed by zamundaaa into branch 'Plasma/6.5'.

backends/drm: fix async present with direct scanout


(cherry picked from commit 62d81edf4073131003e02756cce2b5c7cbdd58fb)

Co-authored-by: Błażej Szczygieł <mumei6102@gmail.com>

M  +1    -1    src/backends/drm/drm_egl_layer.cpp

https://invent.kde.org/plasma/kwin/-/commit/5462921f224c1ec7a597129f416e0feae11ce25c

I think direct scanout and overlays should be allowed with ICC profiles, too, as long as the don't change anything on the screen (e.g. night light is off and we set power efficiency and "sRGB color intensity" to 100% - I guess we're only using VCGT LUT in this case, so why not?). It'll reduce power consumption on e.g. laptops where you want to change only white point and gamma for uncalibrated screen and application is using sRGB surface.

(In reply to username from comment #30)
> (In reply to Zamundaaa from comment #29)
> I couldn't figure out how to copy text from the debug console, so here are
> the screenshots. There's one X11 Unmanaged Window that belongs to Battle.net
> https://imgur.com/a/XHI5q5G
Yeah, that's blocking direct scanout. Idk what to do about taht, it is an "invisible" (but KWin doesn't know that) window above all others.

(In reply to Błażej Szczygieł from comment #33)
> I think direct scanout and overlays should be allowed with ICC profiles,
> too, as long as the don't change anything on the screen (e.g. night light is
> off and we set power efficiency and "sRGB color intensity" to 100% - I guess
> we're only using VCGT LUT in this case, so why not?). It'll reduce power
> consumption on e.g. laptops where you want to change only white point and
> gamma for uncalibrated screen and application is using sRGB surface.
It is allowed.

(In reply to Zamundaaa from comment #34)
> It is allowed.

It's not working, when  I load e.g. "/usr/share/color/icc/krita/sRGB-elle-V2-g10.icc" or "/usr/share/color/icc/colord/Gamma5000K.icc" for testing purpose - 'Compositing' red text is always visible when ICC is applied, sRGB intensity set to 100% (AMD Radeon and Intel).