Game will not launch in SteamOS gamescope session when using Steam Runtime in Flatpak

[R1kaB3rN]

Your system information

• Steam Runtime Version: sniper_platform_0.20240423.85483
• Distribution (e.g. Ubuntu 18.04): SteamOS 3.6.3
• Have you checked for system updates?: [Yes/No] Yes
• What compatibility tool are you using?: [None / Steam Linux Runtime / Proton 5.13+ / older Proton]

Please describe your issue in as much detail as possible:

Game launchers like Heroic and Lutris distribute their applications to the Steam Deck as a Flatpak, and users add those launchers as a non-Steam game to utilize the SteamOS gamecope session features before running their games. However, when running games in Flatpak that uses its own bundle of the Steam Runtime within the SteamOS gamescope session, the game window will not be displayed and the client will just hang with the Steam logo spinner spinning indefinitely. On the other hand, when running the game in Desktop Mode, the game window will be displayed as expected. The same applies when distributing the game launcher as a native application instead as a Flatpak, where the window will be displayed in both sessions. Currently, this is a big issue for users of those launchers, causing them to revert to Wine instead of Proton to run their games.

SLR log when running the application (Flatpak) in the SteamOS gamescope session:
https://gist.github.com/R1kaB3rN/f27ec679c4ed6d1250c979a4ea33e84f

SLR log when running the application (native) in the SteamOS gamescope session:
https://gist.github.com/R1kaB3rN/abe95b52d11eef25269cc21e1175db64

Steps for reproducing this issue:

1. Enter Desktop Mode on SteamOS
2. Download the umu-launcher Flatpak on the Steam Deck
3. tar -xaf umu-flatpak-test.tar.gz
4. flatpak --user remote-add --no-gpg-verify umu-repo umu-repo
5. flatpak --user install umu-repo org.openwinecomponents.umu.umu-launcher
6. Create this script and name it test.sh
7. Add the script as a non-Steam game in the Steam client
8. Enter SteamOS gamescope session
9. Run the test.sh

[Simon McVittie]

When you say "Steam Runtime", do you mean the container runtime that involves pressure-vessel/, the same thing that's distributed on Steam as steamapps/common/SteamLinuxRuntime_sniper?

In the logs attached to this report, it seems that you're using winecfg as a simple substitute for an actual game. Is that correct?

I don't see any error messages in the logs you attached that would indicate that winecfg has crashed or failed to start, or that pressure-vessel has failed before it got as far as launching winecfg. Instead, it looks to me as though it is probably starting OK, but gamescope just isn't making the main window visible the way it is meant to.

If you use a ssh session to inspect the process tree while the "game" is running, do you see a winecfg process running?

If you do, please get its process ID (let's say 12345) and look at /proc/12345/maps with less or similar. Do you see that it has mapped gameoverlayrenderer.so into memory? I would expect it to appear at a path that might look something like /tmp/pressure-vessel-libs-VO37M2/lib64/gameoverlayrenderer.so (which will probably be a symbolic link into /home/deck/.local/share/Steam).

I suspect this might be a problem with the logic in Gamescope that aims to only display the main game window (full-screen), and not display anything that is not the main game window. If that logic relies on the gameoverlayrenderer.so getting LD_PRELOADed into the game executable (does it?), then it wouldn't surprise me if either Flatpak, pressure-vessel, or the combination of the two will interfere with that.

Am I correct to think that the truth table goes like this?

• installed unsandboxed at OS level, run in desktop session, uses its own bundled SteamLinuxRuntime_sniper + a third-party Proton: OK
• installed unsandboxed at OS level, run in Gamescope session as a non-Steam game, uses its own bundled SteamLinuxRuntime_sniper + a third-party Proton: OK, https://gist.github.com/R1kaB3rN/abe95b52d11eef25269cc21e1175db64
• installed as a Flatpak app, run in desktop session, uses its own bundled SteamLinuxRuntime_sniper + a third-party Proton: OK
• installed as a Flatpak app, run in Gamescope session as a non-Steam game, uses its own bundled SteamLinuxRuntime_sniper + a third-party Proton: does not appear, https://gist.github.com/R1kaB3rN/f27ec679c4ed6d1250c979a4ea33e84f
• installed by any mechanism, run by any means, uses Steam's official SteamLinuxRuntime_sniper + any Proton: not tested
• installed by any mechanism, run by any means, uses any SteamLinuxRuntime_sniper + Steam's official Proton: not tested
• installed by any mechanism, run by any means, uses any SteamLinuxRuntime_sniper, native Linux executable: not tested
• installed by any mechanism, run by any means, does not use SteamLinuxRuntime_sniper, native Linux executable: not tested

If that's the case, then I think the first obvious things to try would be to eliminate SteamLinuxRuntime_sniper and Proton by using some simple native Linux executable like xterm or zenity as your "game" payload:

• installed unsandboxed at OS level, run in desktop session, no SteamLinuxRuntime_sniper, no Proton, native Linux executable
• installed unsandboxed at OS level, run in Gamescope session as a non-Steam game, no SteamLinuxRuntime_sniper, no Proton, native Linux executable
• installed as a Flatpak app, run in desktop session, no SteamLinuxRuntime_sniper, no Proton, native Linux executable
• installed as a Flatpak app, run in Gamescope session as a non-Steam game, , no SteamLinuxRuntime_sniper, no Proton, native Linux executable

because that will help to narrow down whether this problem is unique to SteamLinuxRuntime_sniper and/or Proton.

Download the umu-launcher Flatpak on the Steam Deck

How is this compiled? What does it contain, and what Flatpak sandboxing parameters does it have?

[R1kaB3rN]

When you say "Steam Runtime", do you mean the container runtime that involves pressure-vessel/, the same thing that's distributed on Steam as steamapps/common/SteamLinuxRuntime_sniper?

Yes, by Steam Runtime, I mean only the contents contained within the steamrt3 image binary release at this endpoint. The application (umu-launcher) does not use the Scout runtime and only uses the runtime contents of SteamLinuxRuntime_sniper.tar.xz, which includes files such as pressure-vessel and sniper_platform_0.20240423.85483 without modifying its functionality in any way.

In the logs attached to this report, it seems that you're using winecfg as a simple substitute for an actual game. Is that correct?

That's correct.

If you use a ssh session to inspect the process tree while the "game" is running, do you see a winecfg process running?

Yes, I see the winecfg process running and here's the contents of the maps file for that process:
https://gist.github.com/R1kaB3rN/82a6ff2f03a11a0120f3bc36beacdf7a

Also, the above log was generated after building the Flatpak application on the Steam Deck via flatpak-builder with this manifest instead of the umu-launcher tarball I had referenced earlier, which has also been built using that manifest. Here were the steps used to build it:

1. git clone https://github.com/Open-Wine-Components/umu-launcher.git
2. cd packaging/flatpak
3. flatpak-builder --user --install builddir org.openwinecomponents.umu.umu-launcher.yml
4. Run flatpak install when prompted for dependencies

Though, for that tarball I had referenced, I do not know the exact command GloriousEggroll had used to build it nor the system that it was built on. However, you should still run into the same issue.

Am I correct to think that the truth table goes like this?

That's correct. For comparison, here's the maps contents of the glxgears executable that has been copied to the home directory using the Flatpak umu-launcher application:
https://gist.github.com/R1kaB3rN/53d44f5b2bfa926e94b195db09d6a447

Of course, the window still does not display.

Now, here's the contents of maps and an SLR log using the native umu-launcher application for glxgears. In this case, for some reason, window displays as expected in the SteamOS gamescope session.

Please let me know if I can assist you with any more information or testing, and if there's a possible workaround or solution for this in the Steam Runtime. However, if a workaround within the Runtime is not possible and it's gamescope like you suspected, then do you have an idea what the appropriate logic would be?