Fullscreen doesn't pillarbox games in fullscreen mode on KDE 6.2

[KayJay7]

Is there an existing issue for this?

• I have searched the existing issues

Are you using any gamescope patches or a forked version of gamescope?

• The issue occurs on upstream gamescope without any modifications

Current Behavior

The main way I use gamescope is to force pillarboxing on games that need it but don't implement it (e.g. Terraria). I cannot pinpoint when it happened (but I can tell it worked in June) but now gamescope doesn't pillarbox anymore, it just shows the game windows in the upper left corner of the screen, like if it was just a borderless window that doesn't cover the whole screen.

Examples:

I do not think it's an issue with kde, because other fullscreen applications work correctly with pillarboxing. For example, here is Quantum Break in fullscreen pillarboxed:

I have tried both the Wayland and SDL backend, but for some reason the SDL one fails to start. Also, I have tried various combination of commands: with different -S parameters, with -b etc. I'm reporting one of the simpler ones

For some reason, I'm not able to replicate the issue on vkcube or glxgears from terminal. I'm running gamescope -h 100 -w 100 -W 2560 -H 1080 -S integer -F pixel -f -- vkcube and it works as expected. It scales to 1000x1000 and adds black borders.

Steps To Reproduce

1. Launch Terraria from Steam with gamescope -h 1080 -w 1920 -H 1080 -W 2560 -f -- %command% on latest KDE
   • The nested resolution needs to be smaller than the real resolution
2. The game window will not be pillarboxed correctly

Hardware information

- Distro: Fedora 40
- CPU: AMD Ryzen R7 7700x
- GPU: AMD Radeon Vega 56
- Driver Version: Mesa 24.1.7

Software information

- Desktop environment: KDE 6.2.2
- Session type: Wayland
- Gamescope version: ?
	* The output of `gamescope --version` is missing the version number `gamescope version  (gcc 14.2.1)`
	* Dnf reports version 3.15.13
- Gamescope launch command(s): `gamescope -h 1080 -w 1920 -H 1080 -W 2560 -f -- %command%`

Which gamescope backends have the issue you are reporting?

• Wayland (default for nested gamescope)
• DRM (default for embedded gamescope, i.e. gamescope-session)
• SDL
• OpenVR

Logging, screenshots, or anything else

Same screenshot as before:

It even causes a weird effect with mangohud where it overflows from the window, while usually it's cropped at the window borders

[KayJay7]

I tried on a different system, with an Intel graphics UHD 620 (a Thinkpad t480s), and with Gnome 46, pillarboxing works as expected

[Eckoa]

Forcing composition or using sdl will work around it

Likely the same as this issue
#1177

[Kontrabant]

This is probably related to this bug.

In short, the Wayland xdg_toplevel spec says that compositor is supposed to center and mask fullscreen surfaces that don't cover the entire output. KDE/KWin doesn't do this.

[KayJay7]

This is probably related to this bug.

In short, the Wayland xdg_toplevel spec says that compositor is supposed to center and mask fullscreen surfaces that don't cover the entire output. KDE/KWin doesn't do this.

That bug seems to predate KDE 6, while my problem wasn't present a couple of months ago

[matte-schwartz]

@KayJay7 do you know have any idea if it was a plasma update or a Gamescope update that changed the behavior? Or is it unclear. I tried to reproduce this yesterday on Arch and was unable to, Plasma 6.2.2 and Gamescope 3.15.14

[KayJay7]

@KayJay7 do you know have any idea if it was a plasma update or a Gamescope update that changed the behavior? Or is it unclear. I tried to reproduce this yesterday on Arch and was unable to, Plasma 6.2.2 and Gamescope 3.15.14

Unfortunately I do not, I haven't used gamescope in a few months, in the meantime plasma has been updated a couple times.

Later this evening I might be able to find a more precise timespan without using gamescope, and check if there's been any gamescope update in that span.

[KayJay7]

@matte-schwartz So, I'm 100% sure it worked on July 11 and a few days laters (which is when I used it for rain world). Unfortunately, since then gamescope updated three times including one week ago. So I cannot say whether it was a gamescope or plasma update that caused the issue.

[matte-schwartz]

Fedora, right? I'll see if I can check it out sometime soon since I know the way they build gamescope on Fedora relies on a few patches and workarounds not present upstream

[KayJay7]

Yes, Fedora 40. I will also try if I can downgrade gamescope without causing a mass downgrade and see what happens.

By the way, what are those downstream patches for?

[matte-schwartz]

main one i remember is a patch to stop using the included submodules for gamescope and instead compile with their own system library versions, which may not be a 1:1 match for what gamescope itself ships and relies on

https://src.fedoraproject.org/rpms/gamescope/tree/f40

edit: and just to clarify, it might be something else entirely here but its certainly one factor i'd like to be able to eliminate

[KayJay7]

So, the only other version I have available on dnf is 3.14.2, and after downgrading I can't start gamescope neither from steam nor from heroic (though launching it from terminal works). I don't think this is related, and it's probably something minor I did wrong, but I don't understand how to get a log or a console output, so I don't know where to start. Adding PROTON_LOG=1 does nothing because it probably exits before launching proton.

Maybe it has something to do with how steam and heroic are built?

p.s. and re-upgrading gamescope goes back to the previous behaviour

[Tatsh]

Forcing composition or using sdl will work around it

Likely the same as this issue #1177

SDL does get around this but I am running Sims 2 and it randomly freezes requiring me to click to make the game continue. Normal mode does not do this.

Compositing results in a lot of garbage on screen so it's not usable.