feat: Introduce scopebuddy

[HikariKnight]

Proper documentation has now been made! (this will always be up to date!)

Documentation: https://docs.bazzite.gg/Advanced/scopebuddy/

Old PR comment explaining usecase (this will not be updated!)

This is a modified version of @coolavery's script from ValveSoftware/gamescope#835 (comment)
It introduces the scb command which is a symlink to scopebuddy that will do the whole unset LD_PRELOAD for gamescope and re-apply it for %command% song and dance.

scb can replace gamescope in the launch options for games in steam
ex: gamescope -w 1920 -h 1080 -W 2560 -H 1440 -r 180 --hdr-enabled -- %command% --nointro --etc --> scb -w 1920 -h 1080 -W 2560 -H 1440 -r 180 --hdr-enabled -- %command% --nointro --etc

Furthermore if the user has a config file ~/.config/scopebuddy/scb.conf it will be sourced before starting gamescope.
If the above file exists and a config with the games AppID exists in ~/.config/scopebuddy/AppID/ then that file will be loaded instead of the scb.conf unless a custom one is set through the SCB_CONF env var.

The file can set a SCB_GAMESCOPE_ARGS variable to provide scb with default gamescope arguments as long as the user gives scb no arguments before the -- in the launch options, providing any args to scb will make it ignore SCB_GAMESCOPE_ARGS completely and use whatever the user provides in the launch options.

This lets the user apply a default set of env vars and gamescope args that they use regularly for games to avoid messes like
env -u LD_PRELOAD ENABLE_GAMESCOPE_WSI=0 SteamDeck=0 XKB_DEFAULT_LAYOUT=no MANGOHUD_CONFIG=read_cfg,preset=2 gamescope --mangoapp -f -w 2560 -h 1440 -W 2560 -H 1440 -e --force-grab-cursor --hdr-enabled -- env LD_PRELOAD="$LD_PRELOAD" %command%

Instead they can define the defaults in ~/.config/scopebuddy/scb.conf like this

export XKB_DEFAULT_LAYOUT=no
export MANGOHUD_CONFIG=preset=2
SCB_GAMESCOPE_ARGS="--mangoapp -f -w 2560 -h 1440 -W 2560 -H 1440 -r 180 --force-grab-cursor --hdr-enabled -e --adaptive-sync"

now this is simplified in the launch options as
SteamDeck=0 ENABLE_GAMESCOPE_WSI=0 scb -- %command%

If the user wants a specific config they do not need to remember for a specific game (in this example warframe) then they can make an AppID config in ~/.config/scopebuddy/AppID/230410.conf, 230410 is the Steam App ID for warframe. In this we can add

export MANGOHUD_CONFIG=preset=3
export SteamDeck=0
export ENABLE_GAMESCOPE_WSI=0
SCB_GAMESCOPE_ARGS="--mangoapp -f -w 1920 -h 1080 -W 2560 -H 1440 -r 60 --force-grab-cursor --hdr-enabled -e --adaptive-sync"

So now i can set the launch options for warframe to scb -- %command% and it will source ~/.config/scopebuddy/scb.conf then source ~/.config/scopebuddy/AppID/230410.conf which will override anything set by scb.conf if they touch the same variables, in this example it will upscale the game from 1080p to 1440p and limit refresh rate to 60 while setting the SteamDeck and ENABLE_GAMESCOPE_WSI environment variables, change MangoHud to preset 3 and keep the XDG keyboard layout set by scb.conf.
This also means it will run any bash code written in the config file before launching the game too!

Then to not use the gamescope args defined in SCB_GAMESCOPE_ARGS the user just has to supply any gamescope arg like so, as they clearly do not want the defaults then. (current implementation still will apply default env vars though)
scb -r 180 -- %command%

The user can also define a different file that contains different defaults too by overriding SCB_CONF with the new filename.
SCB_CONF=1080_180hz_upscaled_hdr.conf scb -- %command%
this will then load the config from ~/.config/scopebuddy/1080_180hz_upscaled_hdr.conf instead

RFC:

• Unsure if we should make the script not load the config file at all if a gamescope arg is provided or if we should make it just load the env vars
• Should we preemptively have this named something else in prep for upstream fixing this issue?

PROS:

• Fixes overlay when using nested gamescope in most titles
• Gives users a command to use for using nested gamescope with a default set of env vars and args (giving this a purpose once it is fixed upstream)

Limitations:

• %command% has to be in double quotes, args after "%command%" does not need to be quoted unless you would normally fixed with 58f5bf6
• does not fix the overlay in all games (usually games where it didn't work to begin with)
• gamemode.conf will be forced as the only possible default config when running inside gamemode (appid configs will still be loaded as usual if they exist)

[HikariKnight]

@wolfyreload and @Zeglius i would like some input from both of you on this one

[HikariKnight]

Suggested by Crono in discord:

• rename it to scopebuddy with the alias scb

[HikariKnight]

next question would be, do we turn this into a package or something down the line 🤔

[wolfyreload]

@HikariKnight I'm not using this as intended as I'm using it on bazzite-nvidia and it's pretty cool being able to just add scb -- %command% and not need to run the gigantic list of gamescope parameters. I wouldn't jump straight into making a package for it, maybe see what the adoption rate is like first. If people start wanting to use it outside of Bazzite then it will make some sense making a package out of it.

[HikariKnight]

@HikariKnight I'm not using this as intended as I'm using it on bazzite-nvidia and it's pretty cool being able to just add scb -- %command% and not need to run the gigantic list of gamescope parameters. I wouldn't jump straight into making a package for it, maybe see what the adoption rate is like first. If people start wanting to use it outside of Bazzite then it will make some sense making a package out of it.

true or even SCB_CONF=someotherdefaults.conf scb -- %command%

[HikariKnight]

Pretty sure this is feature complete now 😅

[EPOCHvoyager]

Commenting here to see in case someone has more information, but this seems to break menu use in things like Ryujinx (built with Avalonia). Even with the same exact arguments for gamescope — checked with ps ax | grep gamescope — and seemingly identical environment, menus will fullscreen flicker for a brief moment before closing when it is run with scb, but not gamescope directly — where they will work perfectly fine.

I suspect something might be upsetting XWayland, but otherwise am, along with @HikariKnight (who's much smarter than me here), at a loss. Does anyone have a lead as to what would be different in the environment between the two — in a way that might be affecting gamescope's compositing?

P.S.: Do note that I'm testing this script by placing it in /var/usrlocal/bin, not by rebasing.

[HikariKnight]

Commenting here to see in case someone has more information, but this seems to break menu use in things like Ryujinx (built with Avalonia). Even with the same exact arguments for gamescope — checked with ps ax | grep gamescope — and seemingly identical environment, menus will fullscreen flicker for a brief moment before closing when it is run with scb, but not gamescope directly — where they will work perfectly fine.

I suspect something might be upsetting XWayland, but otherwise am, along with @HikariKnight (who's much smarter than me here), at a loss. Does anyone have a lead as to what would be different in the environment between the two — in a way that might be affecting gamescope's compositing?

P.S.: Do note that I'm testing this script by placing it in /var/usrshare/bin, not by rebasing.

at this point i am willing to chalk this up to some incompatibility with how the automatic LD_PRELOAD fix has to be applied, so far it seems either only flatpak applications are affected or only ryujinx, so either its a flatpak incompatibility or ryujinx incompatibility.

Will be merging this into testing soon so that more people can play around with this.

[EPOCHvoyager]

Commenting here to see in case someone has more information, but this seems to break menu use in things like Ryujinx (built with Avalonia). Even with the same exact arguments for gamescope — checked with ps ax | grep gamescope — and seemingly identical environment, menus will fullscreen flicker for a brief moment before closing when it is run with scb, but not gamescope directly — where they will work perfectly fine.

I suspect something might be upsetting XWayland, but otherwise am, along with @HikariKnight (who's much smarter than me here), at a loss. Does anyone have a lead as to what would be different in the environment between the two — in a way that might be affecting gamescope's compositing?

P.S.: Do note that I'm testing this script by placing it in /var/usrlocal/bin, not by rebasing.

Solved by 097e35a.