GAMEPID function can fail and spam the log when using gamescope with USEMANGOAPP

[HanPrower]

System Information

• SteamTinkerLaunch version: v14.0.20240624-1
• Distribution: Arch Linux
• Installation Method: Flatpak

Issue Description

Firstly, just to state, gamescope works in Flatpak as I outlined here: #1148 (comment)

Currently function GAMEPID doesn't appear to make sure it has an actual result and can constantly sit waiting for it, and never find it.

This is more likely to happen with gamescope and USEMANGOAPP as it creates a new X Display and the game window is hidden in there.

Currently on https://github.com/sonic2kk/steamtinkerlaunch/blob/master/steamtinkerlaunch#L7729 the command is trying to find the window name on the active display (or display 0).

The following command assumes that gamescope will be on display 1 and will find the game window:
xwininfo -d :1 $GAMEWINDOW -wm

However, the issue with this is the assumption of displays. I've struggled to figure out a way to find out what displays are available, or gamescope states the display it creates when it's launched.

I see a few "fixes":

1. Check the PID, if it's blank wait for a count of attempts, then stop trying. Which I assume would just throw away the STL process? Alternatively, hit the count and stop actively logging the fails. "Failed to find PID after X attempts. Suppressing logging of further attempts. You may need to kill the process with the STOP button in Steam".
2. Check if MANGOAPP is being used and try a handful of display servers to see if the PID can be gleaned from any (this could also just be useful in general if the command is failing).

Then again, I'm probably missing something obvious somewhere.

Logs

Basically the last 3 lines will repeat forever, until killed via the Stop button in Steam.
steamtinkerlaunch.log

[HanPrower]

I'm probably missing something, or maybe things used to be different, but the process around USEMANGOAPP seems to be convoluted.

If I disable it but then set the gamescope args to --mangoapp -f -w 2560 -h 1440 STL no longer has to try and find the game window and figure out the PID, as when the game closes STL realises gracefully and let's go normally.

I wonder if the current way was a workaround for how it used to be implemented and --mangoapp is a cleaned up implementation?

[sonic2kk]

I'm not currently on my PC and haven't had time to dig into this, but GameScope didn't have a --mangoapp option before. That must be new I think?

The MangoHud and Mangoapp stuff right now to my understanding works by using Mangoapp if MangoHud and GameScope are both enabled, since you aren't supposed to use MangoHud with GameScope (you can, but you shouldn't, is my understanding). Mangoapp also doesn't exit cleanly so SteamTinkerLaunch needs to force kill it. This was an upstream limitation that from what I saw just a few months ago is still needed, but could have changed now.

Thanks for the detailed writeup, I'll take a deeper look into the main issue when I have some time :-)