-
Notifications
You must be signed in to change notification settings - Fork 68
Frequently asked questions (FAQ)
By default, umu-launcher sets the Proton verb waitforexitandrun when launching games, which will cause the current process to wait until an active wineserver process has exited. To run more than one game in the same prefix, you must disable this behavior for subsequent games by setting either PROTON_VERB=runinprefix or PROTON_VERB=run.
Also, it's important that the Proton or wine configuration for each nth game is equivalent except for the PROTON_VERB environment variable. Otherwise, unexpected behavior may occur. For example:
GAMEID=0 umu-run foo
GAMEID=0 PROTON_VERB=runinprefix umu-run foo
However, launching the second game with fsync disabled would be invalid:
GAMEID=0 umu-run foo
GAMEID=0 PROTON_VERB=runinprefix PROTON_NO_FSYNC=1 umu-run foo
To use a Proton build installed in a system path, explicitly set the path in PROTONPATH. For example:
GAMEID=0 PROTONPATH=/usr/share/steam/compatibilitytools.d/proton-ge-custom-bin umu-run foo
umu-launcher only searches $HOME/.local/share/Steam/compatibilitytools.d for UMU-Proton or GE-Proton builds when configured to use the latest Proton build. See the documentation for an example on how to do this.
Proton is compiled and is designed to execute in a runtime environment, and the reason umu-launcher does not search system paths is because compatibility tools there may not all be compiled against the Steam Linux Runtime. Since the goal of this project is for users to run their games through Proton just as it were launched from Steam, using Proton builds that were compiled outside the SLR would be against the project's goals.
By default, pressure-vessel exposes the entirety of the user's home directory and environment variables defined in the compatibility tools interface, while only a subset of the host's filesystem paths to its container.
To make more files available to the Steam Runtime container, set STEAM_COMPAT_LIBRARY_PATHS with a value or colon-delimited values of absolute filesystem paths.
GAMEID=0 STEAM_COMPAT_LIBRARY_PATHS="/foo:/bar" umu-run baz
Alternatively, setting eitherPRESSURE_VESSEL_FILESYSTEMS_RO or PRESSURE_VESSEL_FILESYSTEMS_RW are also valid.
Currently, to launch your game in Steam mode, umu-launcher depends on the Proton verb waitforexitandrun and the app ID that Steam assigned for the non-Steam game. Currently, umu-launcher gets the Steam app ID from Steam's Shader Pre-Caching environment variables, namely:
STEAM_COMPAT_TRANSCODED_MEDIA_PATHSTEAM_COMPAT_MEDIA_PATHSTEAM_FOSSILIZE_DUMP_PATHDXVK_STATE_CACHE_PATH
For the latter, simply ensure that Shader Pre-Caching is enabled in Steam. Otherwise, since umu-launcher@8ed817f, the non-Steam game's app ID will attempted to be derived from the SteamGameId environment variable. If neither conditions are met, umu-launcher will not be able to show the game window and you will continue to see a window with Steam's spinner.
The problem of not being able to see the game's window is currently an upstream issue in gamescope that only affects Flatpak applications in Steam mode as one can find that this issue will not exist when launching the game from the desktop environment instead. The exact cause is still not clear as it involves Flatpak, gamescope, Steam, and pressure-vessel. Nonetheless, the fix for this is to bring the window to the foreground just as Steam or gamescope would for Steam games. It does this by reimplementing Steam mode window management, by acquiring the non-Steam game's (e.g., Lutris, Heroic Games Launcher, etc.) app ID then setting the STEAM_GAME property to a subset of X windows.
Until this issue is properly addressed upstream or when clients do not depend on Steam for overlays and controller support, the aforementioned conditions will be requirements for bringing a game’s window to the foreground.