sonic2kk / steamtinkerlaunch

Linux wrapper tool for use with the Steam client for custom launch options and 3rd party programs
GNU General Public License v3.0
2.14k stars 71 forks source link

Issues with gamescope and gamemode #1024

Closed Martmists-GH closed 8 months ago

Martmists-GH commented 8 months ago

System Information

Issue Description

Enabling gamescope sometimes errors with /usr/bin/gamescope: unrecognized option '--verb=waitforexitandrun'

Gamemode on the other hand is unable to find libgamemodeauto.so.0, which is located at /usr/lib32/libgamemodeauto.so.0

Logs

steamtinkerlaunch.log

sonic2kk commented 8 months ago

In future, please upload your log as a file to GitHub and not to a filehost. For what it's worth, the filehost also warned that your log was laced with a virus. I have found no such traces, however.

Your log looks mostly normal. However, your GameMode path looks wrong. Check where it is installed with which gamemoderun, and ensure that you have the 64bit version installed. STL is building the launch command correctly:

/usr/bin/gamemoderun /usr/bin/gamescope -w 1920 -h 1080 -W 3840 -H 2160 -r 144 -f -e --force-grab-cursor --adaptive-sync --prefer-vk-device -- /home/mart/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun -- /usr/share/steam/compatibilitytools.d/proton-ge-custom/proton waitforexitandrun /home/mart/.local/share/Steam/steamapps/common/Palworld/Palworld.exe

The GameMode error may be a false positive coming from a Proton log, unless you can confirm the GameMode daemon does not start. However, if it does not start, that is likely because of an incorrect path as GameMode should be at /usr/bin/gamemode.

Outside of this, you're using a heavily outdated version of SteamTinkerLaunch, it is not a good idea to use "stable" versions as you end up missing out on features and fixes. You could try updating SteamTinkerLaunch and to match, your version of GameScope (ensuring you're using the latest git version of both ofc).

The GameScope error is really strange and sounds like something is being built incorrectly in the launch command, as --verb=waitforexitandrun should get passed to Proton and not GameScope - which, in the command in your log, it is and this looks like a correct, runnable start command. In fact, you should be able to paste that into terminal manually I think and the game should start.

There were changes to accomodate an updated GameScope version in git, and it could be that your GameScope version is too new. Since STL v12.12 is from March 2023 I don't recommend using that version. It usually causes all kinds of issues when people stick to stable versions of software.

Good luck!

Martmists-GH commented 8 months ago

Gamemode seems to work fine: image And I can confirm it's using a 64-bit gamemode (as lib32-gamemode does not provide an executable, only the .so)

I updated steamtinkerlaunch to the current git master version, but I still get the following:

/usr/bin/gamescope: unrecognized option '--verb=waitforexitandrun'
See --help for a list of options.

As for gamescope, I need to use an old version due to an incompatibility with the NVIDIA driver.

sonic2kk commented 8 months ago

Gamemode seems to work fine

That's good then. Just curious though, where did you see this error message? If it's in a Proton/Steam log, then it's probably safe to ignore.

I updated steamtinkerlaunch to the current git master version, but I still get the following:

I can re-create a crash by pasting in your GameScope commands to STL, with GameScope built from ValveSoftware/gamescope@dc81258c. I cannot re-create it running from Terminal (as long as -e is removed, which is Steam-specific and causes a hang in most cases outside of Steam, although fwiw it's not required anymore afaik).

I am not sure yet which argument is causing the hang, as other GameScope launches are fine in my tests. I'll investigate.

sonic2kk commented 8 months ago

It seems --force-grab-cursor is the culprit.

EDIT: Actually, --prefer-vk-device is also causing a crash. Just using --adaptive-sync works fine, but using --force-grab-cursor and/or --prefer-vk-device seems to be causing crashes either on their own or with other devices (not that --prefer-vk-device and --adaptive-sync do anything when running GameScope in a nested session).

sonic2kk commented 8 months ago

Using these options with the Steam Client will cause game crashes for me, sometimes immediately on start and sometimes a few seconds after game start. However, I will investigate first to see if STL is perhaps building parts of the GameScope arguments incorrectly. I am particularly interested to see if it is handling arguments --with-three-words wrong (since that is the only commonality so far between --prefer-vk-device and --force-grab-cursor).

sonic2kk commented 8 months ago

Huh, I restarted the Steam Client and now I'm not able to replicate any crashing with --force-grab-cursor. It will, however, always crash with --prefer-vk-device. Perhaps I was mistaken earlier and simply forgot to disable this option, or disabled it but did not save the settings.

I can intermittently reproduce a crash from the Steam Client with --prefer-vk-device, but I have a gut feeling there is something else going on here...

sonic2kk commented 8 months ago

I'm getting all kinds of weirdness from the Steam Client (games hanging a few seconds after launch, immediate game crashes, games not launching) when using combinations of -e --force-grab-cursor --adaptive-sync --prefer-vk-device either together or alone, when used with the following working GameScope command: gamescope -w 1920 -h 1080 -W 3840 -H 2160 -f -- %command%

With these options, crashes are intermittent. Without, things work fine, at least in the 5 or so launches I tested with NieR:Automata and Cookie Clicker each (using GE-Proton8-27 and Proton 8.0-5).

With SteamTinkerLaunch, crashing is much more consistent (but not constant) when using -e and/or --prefer-vk-device for some unknown reason.

The fact that this is not a constant crash with STL is the most strange part to me, and indicates an issue with the Steam Client/GameScope.

sonic2kk commented 8 months ago

This is really odd. The following launch options in the Steam Client work for me when pasted in manually: gamescope -w 1920 -h 1080 -W 3840 -H 2160 -r 144 -f -e --force-grab-cursor --adaptive-sync --prefer-vk-device -- %command%

However, the following does not (it's copy and pasted from above but with -r 144 removed): gamescope -w 1920 -h 1080 -W 3840 -H 2160 -f -e --force-grab-cursor --adaptive-sync --prefer-vk-device -- %command% (EDIT: It does work, but results in a game hang, only when using PROTON_LOG=1 gamescope blahblahbah?!)

With SteamTinkerLaunch, both of those fail. Only the following GAMESCOPE_ARGS will work (adding --prefer-vk-device or -e will cause a crash most of the time): -w 1920 -h 1080 -W 3840 -H 2160 -r 144 -f --force-grab-cursor --adaptive-sync --. It is still not consistent though, as sometimes even with -e, things will still work. --prefer-vk-device is the most consistent at causing a crash, but the game is true from the Steam Client (although the Steam Client breaks with GameScope for different reasons).

When using those same GAMESCOPE_ARGS that work with SteamTinkerLaunch, it causes the game to freeze if used as the launch options from Steam: gamescope -w 1920 -h 1080 -W 3840 -H 2160 -r 144 -f --force-grab-cursor --adaptive-sync -- %command%. Using -e from the Steam Client will cause a crash if appended above, unlike the first example.

I wonder if this is an upstream bug of some kind with how GameScope parses incoming commands... This doesn't seem to be really consistent, and there is odd behaviour without SteamTinkerLaunch.

I would be very interested to know if you can see the "unrecognised option" error when running without SteamTinkerLaunch, with some combinations of the above! If you are able to, make note of what combination causes it, and it may be worthwhile reporting it upstream too. I will also try, so that you can reference that the issue is still present on a newer commit.

If you're interested, --waitforexitandrun is something that comes from the Steam Client itself and is used as part of the Steam Linux Runtime to launch games.

sonic2kk commented 8 months ago

I found an interesting issue when troubleshooting #1026. It seems in cases like this, we are parsing some arguments wrong:

gamescope -r 144 --rt --headless

When we then try to parse -r, STL incorrectly looks at --rt. Basically if two flags start with the same letter, things go awry. I remember this happening before, and for one part of the GameScope code, included the -w switch for our grep logic. But it seems like I forgot this in getGameScopeArg. That seems odd to forget, I feel like it was deliberately left out. Or maybe at the time (11 months ago) GameScope was much simpler and this was not an issue.

I managed to catch this because I encountered some odd parsing errors. I think we got (un)lucky with your example as we were only setting checkbox values, and they seemed to get set correctly as 1 when a match was found.

I will do some more testing and open a different PR.


Fwiw, there is still crashing with your SteamTinkerLaunch GAMESCOPE_ARGS: -w 1920 -h 1080 -W 3840 -H 2160 -r 144 -f -e --force-grab-cursor --adaptive-sync --prefer-vk-device.

But there is also still crashing on my end when using them without STL and running directly from the Steam Client. So far, cases that crash with the Steam Client also crash with STL, and games that work with the Steam Client are once again working with SteamTinkerLaunch -- The discrepancy I described above no longer occurs for the most part (-e breaks the Steam Client launch, but works with STL. This happens when only -e is used though in both cases, I tested STL through some manual forcing of the STL GAMESCOPE_ARGS to confirm this).

I will push the changes to a branch and then into a PR.

sonic2kk commented 8 months ago

The changes were merged with #1027 and are available in master now.

In my tests, I think this issue is resolved.

sonic2kk commented 8 months ago

Closing due to lack of response. Please re-open if you have more to add after testing the latest master. 🙂