SUMMARY This concerns the following game: https://store.steampowered.com/app/2478020/Rayz_Arcade_Chronology/ When this game is run in full screen using Proton-GE with no launch options, it activates direct scanout. However, when run using the launch option PROTON_ENABLE_WAYLAND=1, which causes Proton to use Wine Wayland, direct scanout is not activated, even though the game is in full screen. STEPS TO REPRODUCE 1. Enable the show compositing effect from the kwin debug console. 2. Launch the game using Proton-GE without any launch options. 3. Observe that the red compositing text has disappeared, indicating direct scanout. 4. Launch the game using Proton-GE with the launch option PROTON_ENABLE_WAYLAND=1 %command% 5. Observe that compositing is still activated. OBSERVED RESULT Direct scanout does not activate in full screen. EXPECTED RESULT Direct scanout should activate when the game is in full screen. SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.6-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i5-10600K CPU @ 4.10GHz Memory: 32 GiB of RAM (31.3 GiB usable) Graphics Processor: AMD Radeon RX 6700 ADDITIONAL INFORMATION I have attached a screenshot of the game running in native Wayland. What I noticed is that the screenshot shows white bars around the game. These are not visible when actually viewing the game on the screen. The fullscreen implementation is probably weird, but it still works in XWayland. I am willing to do any sorts of tests to get to the bottom of the issue.
The correlation between fullscreen and direct scanout isn't as direct as it might seem. Fullscreen windows just happen to usually cover the whole screen with a single opaque surface, but it's possible that they do more complicated things too. The "white bars" sound like maybe the window isn't fully opaque, and/or is composed of multiple surfaces, which can prevent direct scanout from working. (In reply to fbranemyr from comment #0) > I have attached a screenshot of the game running in native Wayland. What I > noticed is that the screenshot shows white bars around the game. These are > not visible when actually viewing the game on the screen. The fullscreen > implementation is probably weird, but it still works in XWayland. I think you forgot to actually attach it.
Created attachment 189428 [details] Screenshot of the game running in native Wayland. The white frame is not visible when viewed on the screen.
Created attachment 189429 [details] Screenshot of the game running in XWayland. The white frame is visible even when viewed on the screen.
(In reply to Zamundaaa from comment #1) > I think you forgot to actually attach it. I've now attached screenshots of the game running in Wayland and XWayland. In Wayland it seems to have invisible white borders on all four sides, while in XWayland the borders are visible, but only exist on the top and left sides of the screen. Is there any way to check if the game is using multiple or transparent surfaces?
That kind of looks to me like the game is trying to do overscan compensation, and Proton's fullscreen hack for X11 makes it not work correctly. (In reply to fbranemyr from comment #4) > Is there any way to check if the game is using multiple or transparent > surfaces? If you run the game with WAYLAND_DEBUG=1 (just quit it again after it shows up fullscreen) and attach the output of that here, I can check.
Created attachment 189444 [details] Console output logged by launching with WAYLAND_DEBUG=1 PROTON_ENABLE_WAYLAND=1 %command% |& tee /home/florian/Documents/log.txt
(In reply to Zamundaaa from comment #5) > If you run the game with WAYLAND_DEBUG=1 (just quit it again after it shows > up fullscreen) and attach the output of that here, I can check. I've now added a debug log in the attachements.
Alright, it does use a 1920x1200 subsurface, above the main window. But it's completely opaque, so that should in theory not cause any issues. I see that Mesa creates a zwp_linux_dmabuf_feedback_v1#78 and it gets some feedback, but only for compositing and never for direct scanout. So that either means the buffer is already suitable for direct scanout, or KWin doesn't even try to make it suitable. Please attach the output of drm_info as well, then we can check which one is true.
Created attachment 189686 [details] Log from the command drm_info with the game open in fullscreen.
(In reply to Zamundaaa from comment #8) > Please attach the output of drm_info as well, then we can check which one is true. Done
Okay, the format modifier isn't supported for scanout. So this means KWin doesn't even attempt direct scanout.
There were a bunch of overlay and direct scanout related changes in 6.6. Can you check if it still happens?
(In reply to Zamundaaa from comment #12) > There were a bunch of overlay and direct scanout related changes in 6.6. Can > you check if it still happens? Still happens, sadly.
Okay.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9154
Git commit f0dc5e4ff3a428adf6df83966d9d080488bd1db9 by Xaver Hugl. Committed on 05/05/2026 at 18:06. Pushed by zamundaaa into branch 'master'. scene/workspacescene: allow an early exit in the overlay candidate search This fixes direct scanout for situations with opaque subsurfaces that cover the entire screen. Before, when the opaque subsurface was found, it still processed all parent surfaces when unwinding the recursion. In some cases, that added the parent surface to the list, breaking direct scanout for no reason. M +32 -15 src/scene/workspacescene.cpp https://invent.kde.org/plasma/kwin/-/commit/f0dc5e4ff3a428adf6df83966d9d080488bd1db9