Steam Linux Runtime: Fix Native Game Crash When SLR 1.0 is Missing

[sonic2kk]

Fixes #998.

Overview

This PR fixes native Linux games crashing when the SLR 1.0 is not installed. This is because when it is not installed, in setSLRReap, NATIVE_SLRCMD is empty. In such an instance we correctly assume the SLR is not installed, but incorrectly fall back to trying to generate PROTON_SLRCMD. However for native games, if we don't have the SLR installed, this is wrong. This means we're generating a bad SLRCMD and so STL will then think it is installed and try to insert it into the launch command for games (blank string values in arrays create bad strings, i.e. something like "/usr/bin/mangohud" "" "/path/to/game" will cause a crash, the blank string is invalid, but this is the value of the SLRCMD, since it's inserting the blank string for PROTON_SLRCMD, which should only happen if PROTON_SLRCMD is actually set. This results in generating a bad launch command (probably inserts a bad SLRCMD when generating the launch command somewhere).

For some reason, the code assumed when NATIVESLR_CMD was not set, it was okay to fall back to using the Proton SLR CMD. this is wrong and we should only do this fallback as well if PROTON_SLRCMD is defined (which only happens when the SLR is found!).

To fix this issue, we add an else block to only fall back to PROTON_SLRCMD if it is actually set. This means when the SLR is not found we don't incorrectly generate an SLRCMD.

This does not affect anything when the SLR is disabled, as we simply skip all of this code. The only time NATIVE_SLRCMD could be empty for native games is if we don't have SLR 1.0 installed.

Background

Native games will crash if 'Steam Linux Runtime 1.0 (Scout)' is not installed, this is because SteamTinkerLaunch incorrectly tries to fall back to generating a wrong command and does not properly return the empty SLRCMD variable. This leads to generating the launch command incorrectly, as STL thinks the SLR is installed and is valid.

To fix this, we do an extra check to ensure the Proton SLR command is only generated when we're using the Proton SLR, and which avoids us falling back on the Proton SLR codepath when NATIVE_SLRCMD is not set. It is incorrect to assume that because the NATIVE_SLRCMD is not set that we're using Proton, we should only fall back to using PROTON_SLRCMD if we actually set the PROTON_SLRCMD earlier.

Remaining Work

This PR needs a little bit more testing before I am confident that it works. I tested with Half-Life (native) and PowerWash Simulator (GE-Proton8-25), with and without the Steam Linux Runtime enabled, and with some hacky code to force the SLR as not found (if [ -d "$SLR_PATH" ] && [ 1 -eq 2]; then) and it appears to work fine. The SLR is correctly used and the launch command looks valid when the SLR is on and off, and forcing the SLR to be not found for both native and Proton games does not cause any crashes and will also correctly not use the SLR when it it is (presumed) not found. The launch command looks correct in all of these tests, and the logging including the new logging is appearing as expected too.

TODO:

• More testing
• Version bump

[sonic2kk]

This should probably work as-is in testing but I'm going to use this branch for daily driving on top of deliberate game testing to ensure no slip-ups. We need to make sure the SLR is still found and used correctly. This should be the case, because right now on master, we always fall back to PROTON_SLRCMD. But if this wasn't found we wouldn't get that far for Proton games to begin with, and if we did, Proton games would crash when the SLR is not found too (which doesn't happen in testing). Therefore the change to explicitly check for PROTON_SLRCMD being set should not cause any regressions. Maybe because the Proton path just creates an array with one blank string (the native SLR command array has two), but if the string was blank and it still worked, we would've noticed games not using the SLR (and thus causing crashes, and things like using the SLR for Non-Steam Games wouldn't have fixed them to begin with).

So this should be safe, but I want to do more testing.

[sonic2kk]

Will continue testing when I'm better and rebase after #1000, and test various games to make sure this works. Will also try to test with no SLR (there may be a hacky way to manually remove it).

But, this is probably safe, it shouldn't break existing working paths and should only improve stability, so will hopefully get this merged soon.

[sonic2kk]

Rebased after merging #1000. Will continue testing to ensure this doesn't break anything with existing launches and in line with what was posted earlier.

Assuming no issues, this will be ready to merge after a version bump.

[sonic2kk]

This got a lot of testing today with quite a few games, including with a (Proton) Non-Steam Game (Tokyo Xanadu eX+).

I think this is safe to merge. We can use this as a culprit to revert if anything goes horribly wrong.

[sonic2kk]

Version bumped and ShellCheck is green, good to merge.