Forked application rendered on top of actual game

[geekysquirrel]

System Information

• SteamTinkerLaunch version: v12.12
• Distribution: SteamOS
• Installation Method: ProtonUp-Qt

Issue Description

When I use trainers as described here (i.e. "use custom command"/"fork custom command"), for some trainers the forked command is always displayed on top of the game, even if I switch away from the trainer in the steam overlay menu ("STEAM button" -> My game menu (top item) -> Select game application (bottom of the menu)).

It seems others are having similar issues.

I've been wondering what causes the issue. I seem to be able to run some trainers OK (e.g. this one and others that use the same UI) but some others just won't work (e.g. this one and others that use the same UI). However, it doesn't seem to be an issue with that UI only, I've seen it happen for various other trainers, e.g. from Mr. AntiFun where some trainers work and others don't.

Given that SteamOS doesn't have the feature of simultanously launching applications out of the box, I'm assuming the issue is with SteamTinkerLaunch but I may be wrong. I would expect a window to be drawn above every other window when it is selected/given focus.

Logs

steamtinkerlaunch.log

[sonic2kk]

Given that SteamOS doesn't have the feature of simultanously launching applications out of the box, I'm assuming the issue is with SteamTinkerLaunch but I may be wrong. I would expect a window to be drawn above every other window when it is selected/given focus.

This isn't a SteamTinkerLaunch issue. This is to do with how Steam Deck Game Mode handles rendering applications. Given that this happens with some applications and not others, this is further proof that STL is not to blame. It is just GameScope not functioning correctly with multiple windows.

Steam Deck Game Mode runs inside of something called GameScope, which is an isolated compositor for running applications. It does not have good support for multiple application windows.

This is not an issue STL can do much about. You may be able to mitigate the issue by tinkering with the timings for how your applications are launched, or the windowing settings for your game (such as setting it to fullscreen or something).

---

I am not sure why you would consider this a SteamTinkerLaunch issue. All STL does is launch the applications, it doesn't manage rendering them. Once the processes start, rendering is up to the compositor. GameScope has various issues with multiple application windows:

• 796

• 791

• 780

You'll have to try and figure out how to resolve these kinds of issues on their own. Bugs with GameScope are not SteamTinkerLaunch bugs. The windowing should work as expected in Steam Deck Game Mode or, better yet, a Linux desktop with a regular compositing session.

Keep in mind that SteamTinkerLaunch is a Linux Desktop utility that can also run on Steam Deck, so any issues like this that crop up in Game Mode are caused by the Game Mode session (some users report window flickering, etc).

[sonic2kk]

Because this has come up so frequently from Steam Deck users who are very quick to blame SteamTinkerLaunch, I have documented this in the FAQ: https://github.com/sonic2kk/steamtinkerlaunch/wiki/Troubleshooting#steamos-windowing-orderinputresolution-is-broken-with-forked-applications-in-game-mode

[geekysquirrel]

I'm not an expert on SteamOS; just trying to hunt down why this doesn't work and since the issue only occurs when using STL I thought it's worth a shot. Thanks for explaining and adding the section in the FAQs. I'm sure others will appreciate it too :)

[sonic2kk]

No problem, I was a bit grumpy this morning so sorry for my tone (had a rough week...)

I saw you followed up on a GameScope issue. I hope this issue can be resolved for other users. Just to try and explain a little better again: The way STL works is basically this:

• Game is launched from Steam, and it gets fed the Steam launch command for a game, which specifies the executable and launch arguments, some games i.e. Hades and Cookie Clicker, have extra options that are passed to the executable
  • These extra options can even change, such as when you launch a game and it asked i.e. for a different executable or something
• When you use a custom command, that is launched by STL. But that's it! All STL does is build the launch command and use Proton. An example might look like this: /path/to/proton_folder/proton run /path/to/executable_file.exe (arguments can be passed before and after the exe, but this is a basic example)
• After the game/custom program are launched, STL does nothing else. It doesn't manage how applications are rendered, it just launches them and it's up to the compositor (GameScope in this case) to manage how those windows are rendered. It seems in some cases this isn't handled very well, GameScope and the Steam Client on SteamOS probably have very specific workarounds in place for game launchers and not much more
• While the Steam Deck Game Mode session has basic (and in my experience with crash report dialogs, buggy) support for switching windows, this is not present in regular GameScope, so likely this is handled by the Steam Client in Game Mode
  • In Game Mode, the Steam Deck runs the Steam Client itself in Big Picture Mode inside of a GameScope session. This is what makes it lighter than Desktop Mode, which uses the KDE Plasma Destkop Environment, which is heavier (but more featured) than the GameScope session (which is designed to be lightweight).
  • It is my own personal assumption (I don't work for Valve, unfortunately) that the GameScope window switching is handled by the Steam Client in Game Mode. I don't know this for sure, but I would assume this is why window switching is only possible using the Steam Client in a GameScope session in Game Mode
  • There is probably a way in general when using GameScope to do this but I don't believe it's documented, so I am not sure how the Steam Client does it. Even if we knew, however, I am not sure what STL could do. We would have to try and "predict" what the actual game window is and how to give it focus, etc. It's a lot of work and research that might not work, and Steam Deck users are not a priority

[geekysquirrel]

No worries, happens to all of us. Thanks again, this makes a lot of sense. Programming is such a vast field and although I'm familiar with Linux and software engineering in general, I have little experience with game development. Let's see if anything comes out of that issue; in the meantime I think it might be worth exploring whether I can find a workaround in Desktop mode.