Enableing gamescope crashes games

[zany130]

System Information

• SteamTinkerLaunch version: 14.0.20240218-1
• Distribution: Garuda Linux
• Installation Method:AUR

Issue Description

Games crash wen gamescope is enabled in stl settings. running the game with the same launch commands (tools) WITHOUT stl works fine with gamescope

Tested this by running a hat in time with stl and no extra tools/options enabled except gamescope (with no arguments). Game crash with the following in the log ERROR - startGame - Could not determine pid of '/home/zany130/.local/share/Steam/compatibilitytools.d/GE-Proton8-31/files/bin/wineserver'

Then I tried running a hat in time with stl with gamescope disabled. Game ran fine

Then running the same game with gamescope -- %command% in steam with proton-GE set as the compat tool instead of stl. Game ran fine

I tried repeating the tests after a reboot as I have seen that pid error go away before with a reboot (maybe a lingering wine processes or something) and I got the same results, enabling gamescope gives ERROR - startGame - Could not determine pid of '/home/zany130/.local/share/Steam/compatibilitytools.d/GE-Proton8-31/files/bin/wineserver' disabling gamescope runs the game as expected

Logs

noGamescope.log
Gamescope.log

[sonic2kk]

Interesting 😀 This has been a rabbit hole, thanks for reporting!

So, I did some testing, and I'm not convinced this is an STL bug, but it is still very interesting nonetheness. I found recently that GameScope no longer works for me (with and without SteamTinkerLaunch) after the new Wayland backend with ValveSoftware/gamescope@ce1156a - I tested this commit and every commit up to ValveSoftware/gamescope@e48bfc8 (the latest at the time of writing) to confirm that no version worked. The last working version is the one before the new Wayland backend, ValveSoftware/gamescope@14a1db3 (GameScope built from this commit works with and without SteamTinkerLaunch for me). GameScope errors out with the new Wayland backend with:

xdg_backend: Couldn't create Wayland objects.
Failed to create backend.

You can try running Steam from terminal and launching your game with SteamTinkerLaunch and GameScope, and then seeing if you're getting a similar output (you can probably Ctrl+F for Failed to create backend). There's gonna be a lot of noisy output but you should at least find some GameScope-related output if you scroll up far enough. For context, running Steam from terminal allows you to see the "raw" output of tools such as GameScope and to see the same kind of output they give if you run GameScope from terminal.

Now, as for why it works from the commandline and not from Steam, I suspect the binary SteamTinkerLaunch is using and the one being used from the commandline are not the same. If you can open a fresh terminal and confirm that gamescope -- glxgears (or an equally safe command) runs, please run which gamescope from the commandline and see what it returns. Then, check which binary SteamTinkerLaunch is using. It should be /usr/bin/gamescope but if it's not, that might be our problem. It is possible to get into a situation where you have two GameScope installations, and that's what I think is going on here.

If your shell is using /usr/bin/gamescope and if running /usr/bin/gamescope -- %command% works from terminal and as a Steam launch option (with GE-Proton, not STL) but only does not work with SteamTinkerLaunch, then the below is kind of meaningless and we'll need to do more digging.

Otherwise: in your Gamescope.log I can see that the game start command is using /usr/bin/gamescope (This is the typical AUR package install location). However GameScope when installed from source is usually put at /usr/local/bin/gamescope. So, what I think is happening is, SteamTinkerLaunch is using /usr/bin/gamescope but the version your Terminal is using is /usr/local/bin/gamescope.

Your shell might prefer a binary at /usr/local/bin because on your PATH (and mine fwiw) I can see that /usr/local/bin is higher up the pecking order. That means when looking for a binary, it'll look here first. As for why SteamTinkerLaunch may be picking up the wrong binary, I'm not sure, but I have seen SteamTinkerLaunch prefer /usr/bin over /usr/local/bin in the past.

If this is the problem, the first and foremost fix is for upstream to fix it 😄 I will report it upstream as at the very least I'm running into this issue. However as a workaround in the meantime you could manually remove one of the GameScope installations. If you're confident you could try to just remove the binary at either location with sudo rm /path/to/blah, but I've given some steps below for a potentially safer option that I would go with personally - tl;dr /usr/bin/gamescope is probably installed via package manager, so uninstall GameScope using your package manager and then install GameScope from source by checking out the last working commit, ValveSoftware/gamescope@14a1db3, and building that.

This can be a little tricky, but probably the best approach is to remove the install at /usr/bin/gamescope and use a build from source. The one at /usr/bin/gamescope is probably installed from a package manager, so try uninstalling that way because it's tricker to remove the install from source (package managers have an easy uninstall path, source installations of packages typically do not). Then, if you have an install at /usr/local/bin/gamescope this is probably built from source, so you can git clone the GameScope repo, git checkout 14a1db3a57612e5cfbba6d4c19688eafdc6c4043 (a commit before the new Wayland backend) and build following the instructions on the GameScope readme (remembering to run the last command under "Install with"), and then restart Steam and your terminal instances.

There is unfortunately no way yet to check your GameScope binary version (ValveSoftware/gamescope#840), so to check if you have removed the old GameScope install, you can check if /usr/bin/gamescope is gone, and if SteamTinkerLaunch is now using /usr/local/bin/gamescope in your log instead of /usr/bin/gamescope.

[sonic2kk]

If we find out you're running into the same upstream bug that I am, I'll attach the "Third-Party Limitation" label to this issue :-)

My issue has been reported upstream, if our issues are the same, then hopefully we can figure out if it's us or Gamescope having a problem (perhaps Plasma 6.0 will fix things, once it makes its way into the stable Arch repos 😄)

[zany130]

Oh I didn't mention I am using plasma 6 from the testing repos (couldn't wait lol) so that could also be part of my problem, but gamescope git (from the aur) works fine when I run it in steams launch options for the game so I don't think it's a problem with gamescope or plasma as I can run these same games with gamescope just not with STL also enabled in the mix ( I tried disabling gamescope in STL and leaving gamescope in the game launch options with no luck)

Regardless I will try everything you mentioned and see if perhaps I do have a Duplicate gamescope install ( I did manually install from git when I first got plasma 6 installed as I was having issues with the aur package)

EDIT:

If your shell is using /usr/bin/gamescope and if running /usr/bin/gamescope -- %command% works from terminal and as a Steam launch option (with GE-Proton, not STL) but only does not work with SteamTinkerLaunch, then the below is kind of meaningless and we'll need to do more digging.

Yes I seem only to have /usr/bin/gamescope as you can see here

sudo find /usr/ -name "gamescope*"
[sudo] password for zany130:
/usr/bin/gamescope-session-plus (this is for running steam with gamescope in  embedded (same as game mode on the deck)
/usr/bin/gamescope
/usr/lib/systemd/user/[email protected]
/usr/share/applications/gamescope-mimeapps.list
/usr/share/licenses/gamescope-session
/usr/share/licenses/gamescope-session-steam
/usr/share/licenses/gamescope-git
/usr/share/chimera/bin/gamescope-fg (this is a bash script from the chimera package. Doesn't seem to be related)
/usr/share/wayland-sessions/gamescope-session-steam.desktop
/usr/share/wayland-sessions/gamescope-session.desktop
/usr/share/gamescope-session-plus
/usr/share/gamescope-session-plus/gamescope-session-plus

[sonic2kk]

I'll be interested to see if the binaries used are the same. I don't have Plasma 6 yet, waiting on presumably 6.0.1 to make it's way to Arch, but I can't recreate any crash with STL and GameScope that is exclusive to using STL. This could be a tricky one then!

I double-checked and the AUR gamescope-git package is just targetting the latest, although it is possible it's out of date if it didn't pull in the last 2 days (when the GameScope Wayland backend commit went in).

[zany130]

my guess is maybe gamescope git is broken on plasma 5 now? so that is why you where crashing on git, but I did reproduce this issue with gamescope installed from the arch repos ( so it doesn't seem to be a problem exclusive to the latest git) so that wouldn't explain why you can't reproduce the issue unless it is something exclusive to plasma 6....

[sonic2kk]

If you can run Steam from the command line and then reproduce the crash with SteamTinkerLaunch+ GameScope, and look for the GameScope output, that could give us a hint :-) You can Ctrl+F in Konsole for something like wlserver I think.

[zany130]

/usr/bin/gamescope: unrecognized option '--verb=waitforexitandrun'

thats something I wonder if stl command appending logic is going screwy and adding things where its not supposed to....

[sonic2kk]

That kind of reminds me of #1024 (related PR: #1027).

I took another look at your log, this looks like the issue might be with your GameScope arguments, or lack thereof. The launch command has /usr/bin/gamescope /home/zany130/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun --, but look, there's no -- before /usr/bin/gamescope. This means GameScope is interpreting /home/zany130/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun as its command, and thus, trying to use --verb=waitforexitandrun as a flag!

Double-check your GameScope args on the Game Menu and see if they're empty, and if they are, try adding -- and seeing if that works.

I'm double-checking with a fresh config but I'm pretty sure this arg is meant to be the default. I also thought we had logic in place to force GAMESCOPE_ARGS to be -- if they were blank.

[sonic2kk]

With a fresh config, the GameScope args do appear to default to --, since GameScope usage is gamescope --flag -switch -x -y --blahblah -- commandgoeshere. I also tested that removing -- from the GameScope args will cause a crash.

When the args are blank, GAMESCOPE_ARGS appears to get set to none, which means they are ignored and thus the start command becomes /path/to/gamescope /path/to/executable --verb=waitforexitandrun -- blahlbalh.

Looks like we need better detection of blank GameScope args!

[zany130]

huh yup that indeed did alow my game to launch I was using no args to see if that helps with the crashing. ill try again with the args (and also test those same args in steam launch command)

so its possible that my original issue was a bug outside of stl but it lead to this by testing no args lol

[sonic2kk]

It's all good though this uncovered quite the oversight, even in the code we are deliberatly ignoring GameScope arguments altogether when it's $NON: https://github.com/sonic2kk/steamtinkerlaunch/blob/c88bccf5794ddfd7e411c5ad7ecd7a7743e585d1/steamtinkerlaunch#L19960

Sorry for sending you down a complete rabbit hole, when the actual fix was much simpler 😞 But if that has fixed your issue I'm very glad! I'll leave this issue open for further discussion and also until I can push a fix. Gonna remove that != "$NON") check and replace it with a check for NON and empty args, and then default to -- for the GAMESCOPEARGSARR (this allows us to keep the "none" text visually on the UI but internally handle this case by defaulting to --) and return early.

[sonic2kk]

This has also revealed a related unhandled case, where if you pass GameScope arguments but do not end them with --, a crash occurs for the same reason. The fix for this might be slightly more involved, as I would like to not just handle this by appending -- to GAMESCOPEARGSARR, but also to update the GAMESCOPE_ARGS config variable, to avoid the GameScope args from getting into a broken state. Updating the config variable is the part that might be slightly more work, which is why it'll go in a separate PR (it may already be handled but I'd prefer investigate in a separate PR to be safe and save on testing too much in one PR).

It's surprising this wasn't caught yet, but this issue helped bring it to light.

[zany130]

hmm so I tried just adding resolution args so

-w 2560 -h 1440 -W 3840 -H 2160

and I get

/usr/bin/gamescope: invalid option -- 'l'
See --help for a list of options.

in the terminal I have steam running
same args work when adding it as a steam launch command

no idea where its get the l from though

so something may be wrong on how its writing out the final launch command? Ill post the stl log now

[sonic2kk]

The arg string you gave is missing -- from the end. Maybe that's part of the issue?

[zany130]

yup lol that's the issue

[sonic2kk]

I posted a comment like a few seconds before yours, but I caught this issue at the same time 😆 (#1048 (comment)) And I will work on a fix for it too tonight, but in a separate PR. I think it makes sense to handle this case also, as there is no reason to allow gamescope args to get into a broken state in this way. We can't do anything about improperly input commands, but we can handle "syntax" cases like this where -- was not appended.

Also fwiw, you can use the GameScope GUI menu, which should build the launch option correctly. Although if you're missing "--" I wonder if it'll read it correctly! I haven't checked how it handles this case, or blank arguments.

[zany130]

So fwiw I figured out my problem it was actually several issues.

1. fullscreen mode was broken with the new wayland backend commit I think that might be what I was hitting originaly
2. gamescope git + mangohud git seems to be currently broken giving this
   
3. Is the issue discovered here where -- is not being written out automatically and causes a crash.
   FWIW I always use the GameScope GUI menu (super helpful) so seems like that wasn't writing out the -- at the end

sorry for dragging you down this rabbit hole with me 😆

[sonic2kk]

Those seem like nasty issues! If you build from git (or if you want to modify the gamescope-git PKGBUILD yourself heh) you can rollback to the latest commit before the Wayland backend, ValveSoftware/gamescope@14a1db3 (that's what I'm currently working off of as it appears GameScope git is broken in Plasma 5 now).

I also noted on my GameScope issue that the issue may be specific to Plasma 5, as it looks like (with a couple caveats) GameScope is running for you on Plasma 6.

[sonic2kk]

#1049 should fix this, just gonna do a bit more testing and then merge it later tonight.

The fix for a full arguments list missing -- at the end might take longer, I'm not sure of the best way to handle it. I don't know if writing out GAMESCOPE_ARGS is great to do in gameScopeArgs, since we are "agnostic" about what arguments we're given. We just build an arguments array that we can send to the start command, but this should usually be the same as the GAMESCOPE_ARGS string.

We don't have to handle updating the argument string, we could just handle it internally when we're building the GameScope array in gameScopeArgs which would handle any GameScope launch string, but I would like to handle updating the GAMESCOPE_ARG string... We'll see.

[sonic2kk]

For simplicity sake, I will leave out the updating of the GAMESCOPE_ARG variable. Instead, STL will append -- when it is missing, but will log a warning that the GameScope args are invalid.

If the user updates their GameScope command from the GUI, this will get fixed anyway, as when we save the GameScope args using the GUI function, we append -- to the end of the string we build regardless, so long as the user presses "DONE" (https://github.com/sonic2kk/steamtinkerlaunch/blob/master/steamtinkerlaunch#L11728).

[sonic2kk]

#1049 was merged, meaning empty GameScope arguments will now have -- appended automatically.

The issue with -- causing crashes if it is missing from the end of a GameScope start command will be resolved with #1050, which will resolve the remainder of this issue.

Note that neither #1049 nor #1050 will actually update the GAMESCOPE_ARGS config variable. So visually, empty GameScope args will still say none, and an argument string that is complete but missing -- at the end (i.e. -w 1280 -h 720 -W 1280 -H 720) will still be missing the -- at the end. SteamTinkerLaunch handles these cases internally, and when using GAMESCOPE_ARGS string to build the GameScope arguments array to pass to the launch command, we catch if the string is missing -- or if it is empty, and update/append as needed to avoid the crash in this issue.

I am not sure why this was not done before, but so far I am not seeing any regressions. There have been massive changes to our GameScope handling in the last 18 months including changes to gameScopeArgs (#744 did a huge change to how we build the GameScope args), so perhaps if there was something preventing this in the past, it has since become irrelevant.

Once #1050 is merged this issue should be closed automatically :-)