KWin Direct Scanout does not work with gamescope

[NjlsShade]

When running gamescope in a fullscreen window using KDE Plasma 6, direct scanout does not work. Is it possible to get it functioning, or is there compositing going on in a way that just won't allow it though kwin?

I've tried using the -f flag, as well as using kwin to make the standard gamescope window boarderless fullscreen. Nothing else is overlaying the window when testing.

[Zamundaaa]

Can you give some more information? What exact version of Plasma are you on, do you have HDR enabled, do you have an ICC profile set or the built-in profile, is the screen rotated? Also, what are you doing to check if you get direct scanout?

[NjlsShade]

I'm running Plasma 6.1.2 on Fedora 40, however, it's been an issue since Plasma 5. I'm not using HDR, monitor is using built-in color profile, screen is in default landscape orientation and gamescope is matching the resolution 1:1 (2560x1440).

I can show that direct scanout is not working because MangoHud's current FPS stats will reset when the compositor enables/disables it for the parent window, and there is also a telltale stutter during this process. I've attached a video to show how it looks when it's functioning properly (stutter is not noticeable at the video's frame rate, but MangoHud is). You'll notice that when something is composited over the window (the microphone mute indicator in this case) it disables direct scanout during the duration, then re-enables it.

Thanks!

https://github.com/user-attachments/assets/9ee2c30b-bac1-4da0-9305-ed043bb59402

[Zamundaaa]

monitor is using built-in color profile

In Plasma 6.1 that forces compositing; offloading volor management to KMS has only been implemented recently, for 6.2. If you set the color profile to "none", that should make direct scanout work again

[NjlsShade]

monitor is using built-in color profile

In Plasma 6.1 that forces compositing; offloading volor management to KMS has only been implemented recently, for 6.2. If you set the color profile to "none", that should make direct scanout work again

I apologize, my statement that the monitor was using the "Built-in" profile was ignorant (thought None referred to the built-in one). The option in KDE's settings is currently set to "None"

Note that direct scanout also works just fine in games, as long as I'm not using gamescope.

[Zamundaaa]

Okay, interesting. Direct scanout does work for me in Plasma 6.1 FWIW. Maybe it depends on the GPU? I'm on a rx 7900XTX

[NjlsShade]

Thanks for the info! I'm running gamescope with:

gamescope -w 2560 -h 1440 -f

Are there any extra flags needed to allow this, and how are you testing if it's working for you?

[Joshua-Ashton]

I can show that direct scanout is not working because MangoHud's current FPS stats will reset when the compositor enables/disables it for the parent window, and there is also a telltale stutter during this process. 

I don't think that would happen with Gamescope, so perhaps your testing methodology for knowing if direct scanout is enabled is what is wrong here?

[Joshua-Ashton]

Worth noting that --mangoapp also uses a separate wl_surface to display, which would stop direct scanout on KWin right now as it only uses the primary plane fwiu.

The DRM Gamescope backend aggressively uses planes.

[NjlsShade]

I can show that direct scanout is not working because MangoHud's current FPS stats will reset when the compositor enables/disables it for the parent window, and there is also a telltale stutter during this process. 

I don't think that would happen with Gamescope, so perhaps your testing methodology for knowing if direct scanout is enabled is what is wrong here?

Yeah, you are definitely right there, as MangoHud is running within the scope of gamescope. I'd imagine that I'd still see a stutter when overlaying content like the microphone mute indicator though (maybe I'm wrong, maybe it's not a stutter in KWin but the game itself during the switch so it would not be visible in this setup?), and I'm not seeing that when using gamescope, even without MangoHud running. You familiar with any way I can test outside these methods?

I know that's kind of outside the scope of this issue tracker, but Plasma has a bug where animations will get stuck and break direct scanout occasionally, and having an easy way to know if it's broken would be nice so I can be sure it's not a given game just acting up, and to let me for sure know this issue is resolved. haha

[Zamundaaa]

You can check if direct scanout is kicking in with drm_info. KWin uses buffer formats with alpha, and games generally use formats without alpha. On my desktop:

drm_info | grep Format:
    │   │   │   ├───Format: ABGR2101010 (0x30334241)
    │       │   ├───Format: ABGR2101010 (0x30334241)

With doom eternal in gamescope:

sleep 5; drm_info | grep Format:
    │   │   │   ├───Format: XBGR2101010 (0x30334258)
    │       │   ├───Format: XBGR2101010 (0x30334258)

[NjlsShade]

Replying to https://github.com/ValveSoftware/gamescope/issues/1423#issuecomment-2236810356

Thanks for that information! Using that as a method to check, I can confirm that direct scanout is still not working with gamescope for me, even with no overlays enabled. Just running: gamescope -w 2560 -h 1440 -f -- %command%

I have the terminal running on a different monitor, and it does show working for games outside gamescope, so It's not interfering in any way. May I ask how you are running gamescope, and what your launch options are?

[Zamundaaa]

I don't use any special flags except for enabling HDR, just gamescope -W 5120 -H 1440 -f --hdr-enabled -- %command%