Generic Gamescope session tweaks

[zany130]

Steam Game Mode (also referred to as gamescope-session or steam-gamescope-session)
It is no longer limited to Steam OS.

This PR moves some of the Steam Game Mode-specific tweaks out of the check for Steam OS (but still in the same function. I am not sure if I should put it elsewhere, but it made sense to me to leave it there)

I also made the sizing fixes apply to all Steam decks, not just Steam OS.

Not all of the Steam deck tweaks are desirable outside of Steam OS, even when still running on a Steam deck (mainly the dependencies stuff)

Basically, it comes down to

non-steam deck hardware running some Steam OS-like distro (or using something like https://aur.archlinux.org/packages/gamescope-session-steam-git)

• Disable Tray indicator
• Disable Notifyer
• Disable Mangohud/ Mangopeel
• Disable Gamescope Settings
• Disable Feral Game Mode
• Force DXVK_HDR=1
• Make sure YAD windows are sized correctly in Gamescope (rn its running as a tiny window; I think it may be because of FSR)
  

Steam deck running some Steam OS like distro (ex bazzite)

This should do everything we currently do for Steam deck running Steam OS minus the dependencies stuff

• Disable Tray indicator
• Disable Notifyer
• Disable Mangohud/ Mangopeel
• Disable Gamescope Settings
• Disable Feral Game Mode
• Force DXVK_HDR=1
• More sizing fixes fixes for specific for the Steam decks screen

[zany130]

may take awhile before this is ready to be reviewed/tested

I'm currently running into a major bug that's breaking Gamescope FSR when I use this. (not sure how to really describe it's as if the game keeps changing resolution)

This does not happen on the latest master so its something I did here

I will try to look at it more in-depth this weekend, but it looks like this won't be as straight forward as I thought

[sonic2kk]

I haven't had time for a proper review or anything, and this PR is in draft, but I think the general idea makes sense. I have some notes though

This PR moves some of the Steam Game Mode-specific tweaks out of the check for Steam OS (but still in the same function. I am not sure if I should put it elsewhere, but it made sense to me to leave it there)

I aim very torn on how this should be handled, and is really the main thing I wanted to note here before too much more work goes into it.

The main thing we want to do here is to introduce a code path to include some (most?) of the Steam Deck Game Mode running behaviour but for other GameScope embedded sessions, like those on other handhelds running a GameScope session.

We already have a variable that checks for a GameScope embedded session, it's called FIXGAMESCOPE. But this is only checked for on Steam Deck. I am assuming at the moment that this check is valid outside of Steam Deck as well to determine an embedded GameScope session. In other words, if we perform this check on each boot of SteamTinkerLaunch, it would:

• Correctly detect an embedded GameScope session.
• Not affect regular SteamTinkerLaunch usage.

This might be a wrong assumption! But if it is correct, then we could refactor as follows:

• Decouple the check for FIXGAMESCOPE from steamdedeckt (I think it's in there anyway) so that it is always ran and checked. This will allow us to know if we're running on an embedded GameScope session on any device, which makes sense. We would always want to check for this, since before FIXGAMESCOPE would have only really almost exclusively applied on Steam Deck. But as you point out, we could have an embedded session outside of Steam Deck on a variety of devices and setups.
• In places where we check FIXGAMESCOPE, we probably also always preface it with a check for ONSTEAMDECK, for example with MangoHUD stuff iirc. In the functions where we check for FIXGAMESCOPE we should decouple them from the ONSTEAMDECK check, meaning those functions don't care if we're on Steam Deck or not, they only care if we're running in an embedded GameScope session.
  • Essentially in places where we check for ONSTEAMDECK and then FIXGAMESCOPE, we could probably change that logic to only check for FIXGAMESCOPE.
  • I am not sure if this kind of change has any impact to a path where we're "on Steam Deck but not in Game Mode". I think for the purposes of this PR, every case where we're on Steam Deck but not in Game Mode (where FIXGAMESCOPE=0), the behaviour should be identical to regular Desktop Mode.
    • One exception here might be when setting windowing sizes for Yad in Desktop Mode, I think that's how we use the SMALLDESK variable. But if we want to handle that, we could have a different PR where we set SMALLDESK=1 in a check for handhelds or, better yet, smaller screen resolutions in general.

From looking at the code it seems like this is the general direction perhaps, but I wanted to call out that I think this is the best approach: Keep the Steam Deck-specific stuff as-is mostly, but change the logic that sets FIXGAMESCOPE=1 so that it can check this regardless of whether or not we're on Steam Deck (and the check for this could go in a separate function, that gets called before steamdedeckt in the main function). Then, in functions that check FIXGAMESCOPE, decouple them from any Steam Deck-specific checks. For example:

# Code could go from looking like this:
if [ "$ONSTEAMDECK" -eq 1 ]; then
    if [ "$FIXGAMESCOPE" -eq 1 ]; then
        # ...
    fi
fi

# ... to looking like this:
if [ "$FIXGAMESCOPE" -eq 1 ]; then
    # ...
fi

This means functions that handle things like the tray indicator and stuff being turned off if we're in an embedded GameScope session will not be tied specifically to the condition ONSTEAMDECK && FIXGAMESCOPE.

---

Didn't review the code too in-depth or anything, but let me know if there's anything you want me to take a look at even while this PR is in draft. And let me know if that suggested approach doesn't make much sense and I can try to clarify or we can discuss further.

I don't know how straightforward the changes overall will be, I appreciate too that the Steam Deck part of the code is not the most well-kept. So again I'm happy to discuss and help out however I can here. Hopefully this isn't all too difficult to untangle though :-)

[sonic2kk]

Also should say I really appreciate the initiative here! I think this is part of the Steam Deck integration that was a bit short-sighted, and it crossed my mind a few times for how we would handle this once SteamOS comes to the Desktop (SoonTM ValveTime, but it is coming eventually). This is an important step in that direction I feel like.

I don't use my Steam Deck much, and don't plan on getting any other handhelds or using a GameScope session anytime soon, so this is not something I have a setup on hand to target with development. But it should benefit a lot of users who do!

I should also clarify (normally would be an edit, but since I'm leaving an extra comment, I'll note it here too) that the reason as well that I'm interested in just using FIXGAMESCOPE is that the other handhelds and platforms with embedded sessions don't require the other Steam Deck-specific tweaks, like downloading dependencies (Steam Deck probably doesn't need it either I think since we could just use the Yad AppImage normally in ~/.config/steamtinkerlaunch/downloads but that's a different can of worms for another day!). All we need here is to generically force certain SteamTinkerLaunch configurations (like disabling the tray indicator, etc) if we're in an embedded session (i.e. if FIXGAMESCOPE=1). It doesn't matter what device we're on, and this PR would effectively let us decouple that logic and solve that problem; untangle what is effectively GameScope embedded checks (FIXGAMESCOPE) from whether we're on Steam Deck and need known Steam Deck tweaks (ONSTEAMDECK).

P.S. - I will probably merge #1111 first, and this PR might need a rebase. Hopefully not anything significant, but if there are headaches there, I can help out with trying to rebase :-)

[zany130]

Yup totally agree with your approach.

That's more or less what I was trying to do.

Leave the steam deck specific stuff mostly untouched (the only thing I'm think of expanding is how it detects a steam deck rn it's looking in`/etc/os-release' for "steam deck"

I'm thinking of changing that to look for "Valve" as the system manufacturer like this

if [ -f "/sys/class/dmi/id/sys_vendor" ] && grep -q "Valve" "/sys/class/dmi/id/sys_vendor"; then

That way the steam deck specific tweaks like the edited gtk.css
For bigger scroll bars can apply even outside of steam os

Though we still wouldn't want the dependencies stuff as pretty much every distro you would want to run on a handheld (bazzite, chimera, nobara,holo) already has all of STL hard deps including yad and innoextract. Only steamos doesn't have yad I think (or innoextract)

So I would like to still leave a check for steamos

For the dependencies stuff
I thought about making it more generic and just checking for screen resolution but theoreticaly a monitor could be running at 720p for example

Or what if the user purposely set such a low resolution for an old game?

Sure with FSR you don't really need to set your whole desktop to a low res but still

[zany130]

Huh this is really strange
both line https://github.com/zany130/steamtinkerlaunch/blob/fc43dba37d80c83bebeac0ff1c331436d2b7fe99/steamtinkerlaunch#L26250
and line https://github.com/zany130/steamtinkerlaunch/blob/fc43dba37d80c83bebeac0ff1c331436d2b7fe99/steamtinkerlaunch#L26251
are running fine

but everything else that checks for

if [ "$FIXGAMESCOPE" -eq 1 ]

does not.

And more importantly this line is not running

https://github.com/zany130/steamtinkerlaunch/blob/fc43dba37d80c83bebeac0ff1c331436d2b7fe99/steamtinkerlaunch#L26626

so how is FIXGAMESCOPE getting set to 1 😕

2138610.log

NVM those log messages in
https://github.com/zany130/steamtinkerlaunch/blob/fc43dba37d80c83bebeac0ff1c331436d2b7fe99/steamtinkerlaunch#L26265

Are a little misleading now since I didn't have USEGAMESCOPE USEGAMEMODERUN enabled its going into the else statement were it allowing x in desktop mode

So it looks like it actually is passing all the

if [ "$FIXGAMESCOPE" -eq 1 ]

checks

The only thing... there is actually no improvement from enabling all the STL tweaks to gamemode 😞

GUI is still scaled badly as in the above image, and actually, FSR is now broken (causes flickering. No idea why)

So, the experience in game mode is actually worse now.

I'll try to play with it a bit and see if I can fix yad sizing in Gamescope on the desktop. Otherwise, maybe I will reduce the scope of the PR to apply Steam deck tweaks regardless of OS and forget about game scope on the desktop

[sonic2kk]

and forget about game scope on the desktop

GameScope tweaks probably don't need to apply on the desktop, I don't see any benefit there because you'd actually want the notifier and tray icon etc. The Steam Deck tweaks should only apply in GameScope embedded sessions.

Unless I'm misunderstanding something?

[zany130]

Oh no, when I said desktop, I was referring to running the steam game mode stuff outside of a portable system like the steam deck

They we have a fix screen size and it should be easier to get everything sized correctly

Really, that's all the Steam game mode tweaks come down to. Sizing yad correctly for the decks small screen and disabling options that you don't need/want in steam game mode like gamescope, mangohud, and feral gamemode
which at least on my bazzite system enabling feral gamemode while also using the steam game mode causes a crash

There is also something for navigating the UI with a controller but never used that before, or know how to get that to work 😅

[zany130]

May be a dumb idea but maybe we can grab steam game modes gamescope resolution from it's command line arguments

And set WINX and WINY (I think that controller the size of the use window) to that.

The added benefit of this is it will automatically uses the screen resolution the steam deck and other handhelds when running there

[sonic2kk]

May be a dumb idea but maybe we can grab steam game modes gamescope resolution from it's command line arguments

I don't know if there's a way to get the GameScope resolution that way. But yeah you raise a good point, on desktops that use a GameScope embedded session they probably wouldn't want the window size set so small.

I wonder if we need to set the size at all in a GameScope session. Can the SteamTinkerLaunch dialog even exceed the size of the GameScope window? I know GameScope handles dialog windows in some funky ways sometimes especially if they are dialogs without a typical "parent".

[zany130]

I wonder if we need to set the size at all in a GameScope session. Can the SteamTinkerLaunch dialog even exceed the size of the GameScope window?

Im not really worried so much about that as I am this

apparently from looking at the logs and the code

STL tries to detect the screen resolution and size yad accordingly here https://github.com/sonic2kk/steamtinkerlaunch/blob/c174a06f1b98d2aa523fe93e2afaed2713f46563/steamtinkerlaunch#L10604

but for some reason on steam gamescope (and I tried disabling FSR to see if it would help)

it detected the screen resolution as a fraction of the real screen size. I think it was something like 1378x700 or some other weird res .

EDIT: this was the res I was seeing setInitWinXY - Using '1440x810' from config '/dev/shm/steamtinkerlaunch/defres.txt' for refence my screen res was 3840x2160 thats what I expected YAD to scale to. I belive I did have FSR but I was scalling 1440p to 4k

Im wondering if we gan grab the resolution arguments gamescope was run with using pgrep -a gamescope for example

pgrep -a gamescope                                                                                                                                                                                                                                    
557658 gamescope -w 3840 -h 2160 -W 3840 -H 2160 -r 120 -o 30 -f -- vkcube
557692 gamescopereaper -- vkcube

and size yad to that

Thats really the only benefit this PR will bring to gamescope session. The rest is just disabling options we don't want/need/can crash in a gamescope session

[sonic2kk]

We could possibly grab the resolution from that command by using getGameScopeArg, if you are able to get that output from SteamTinkerLaunch you can take the output of that command and use head -n1 (assuming the GameScope command will always be the first result). You can check how we use this for -w/-h/-W/-H in getGameScopeGeneralOpts:

# Get the GameScope command from pgrep
FIXGAMESCOPESTARTCMD="$( pgrep -a "$GAMESCOPE" | head -n1 )"

# ...
# There should probably be some check here where if there is no found GameScope start command to bail out
# ...

# 1280 and 720 are defaults if no value is returned for width and height respectively.
# We could replace these defaults with whatever the autodetected width and height variable is.
#
# Variable names can be whatever you want, just make sure the name you assign and the name in the argument match
THISISMYWIDTHVARIABLE="$( getGameScopeArg "$FIXGAMESCOPESTARTCMD" "-W" "$THISISMYWIDTHVARIABLE" "" "1280" "num")"
THISISMYHEIGHTVARIABLE="$( getGameScopeArg "$FIXGAMESCOPESTARTCMD" "-H" "$THISISMYHEIGHTVARIABLE" "" "720" "num")"

writelog "INFO" "${FUNCNAME[0]} - GameScope resolution from pgrep is '${THISISMYWIDTH}x${THISISMYHEIGHT}'"

Note that we should make sure this only happens on embedded GameScope sessions, we don't want to change window sizing behaviour on the Desktop.

[sonic2kk]

Thats really the only benefit this PR will bring to gamescope session. The rest is just disabling options we don't want/need/can crash in a gamescope session

So to clarify, the goal of this PR is still to:

• Disable certain things that we don't need in an embedded GameScope session, like the Tray Icon, Notifier, etc. Things that have no effect and/or could potentially cause issues in an embedded GameScope session. To essentially apply the tweaks that we apply on SteamOS but in any embedded GameScope session.
• Apply some sizing tweaks so that the SteamTinkerLaunch dialog is sized correctly in an embedded GameScope session (i.e. takes up the full screen size)

[zany130]

For generic hardware

this PR will only ensure the yad window takes up the full screen size and disable

1. mangohud/mangoapp
2. gamemode
3. gamescope options
4. tray
5. notifer
6. force enable DXVK_HDR=1 ( I think this is no longer nessicarry?)

For Steamdeck

EDIT: ofc mangohud,gamemode, etc would also be disabled here

the plan still is to try to get the more extensive sizing from Steamos to apply generically to all Steam decks

This includes some CSS tweaks to make the scrollbar easier to use, and tweaks to the column and headers of yad

If my screen sizing on generic hardware works like I expect it to I think we can remove the code that forces yad to the decks resolution https://github.com/sonic2kk/steamtinkerlaunch/blob/c174a06f1b98d2aa523fe93e2afaed2713f46563/steamtinkerlaunch#L2059

(maybe this can be expanded to all handheld PCs in the future, but the only way I can see this working is to code the values for several different devices hard, i.e., I don't like the idea of just applying tweaks to devices below a certain res.)

maybe for both

If I can figure out the gamepad support, I would like to decouple it from Steamers, but it's not a high priority, and from what I understand, it's a very hacky approach to getting gamepad support in STL.

I would only put this behind the FIXGAMESCOPE arg and not the steamdeck check as it could also be helpful on generic hardware.

I think I will make that a separate PR if decide to work on that

[sonic2kk]

Thanks for the clarification. Right now I think that makes sense.

If I can figure out the gamepad support, I would like to decouple it from Steamers, but it's not a high priority, and from what I understand, it's a very hacky approach to getting gamepad support in STL.

Yeah, personally I would not bother. I was considering stripping out the gamepad stuff because it's a bit too hacky to be useful imo. I also do not care for using GUI programs with a controller on SteamOS, and it is not something I think makes sense to shoehorn into a traditional keyboard and mouse program like SteamTinkerLaunch.

[zany130]

if anything, maybe I should publish a steam input profile for STL on the deck controller and call it a day 😅 would be easier

[zany130]

So, here is some good news: I was able to fix the YAD sizing by hard-coding my screen's resolution, so it looks like that indeed is the problem. For some reason, it's not detecting the correct resolution when running through the game scope.

The bad news is I haven't been able to get it to auto-detect the resolution from the game scope arguments

I tried (btw renamed FIXGAMESCOPE to GAMESCOPESESS)

function pollWinRes {
....

	if [ "$GAMESCOPESESS" -eq 1 ]; then
		# Get the GameScope command from pgrep
		GAMESCOPESESSSTARTCMD="$( pgrep -a "$GAMESCOPE" | head -n1 )"
		
		# ...
		# There should probably be some check here where if there is no found GameScope start command to bail out
		# ...
		
		# 1280 and 720 are defaults if no value is returned for width and height respectively.
		# We could replace these defaults with whatever the autodetected width and height variable is.
		#
		# Variable names can be whatever you want, just make sure the name you assign and the name in the argument match
		GAMESCOPESESSX="$( getGameScopeArg "$GAMESCOPESESSSTARTCMD" "-W" "$GAMESCOPESESSX" "" "1280" "num")"
		GAMESCOPESESSY="$( getGameScopeArg "$GAMESCOPESESSSTARTCMD" "-H" "$GAMESCOPESESSY" "" "720" "num")"
		
		writelog "INFO" "${FUNCNAME[0]} - GameScope resolution from pgrep is '${GAMESCOPESESSX}x${GAMESCOPESESSY}'"
		
		SCREENRES="${GAMESCOPESESSX}x${GAMESCOPESESSY}"
		WINX="$GAMESCOPESESSX"
		WINY="$GAMESCOPESESSY"
		setGeom
	else
		SCREENRES="$(getScreenRes r)"
	fi
....

but it looks like its not getting the anything from gamescope

Sat Sep 21 11:05:38 PM EDT 2024 INFO - pollWinRes - GameScope resolution from pgrep is 'x'

[zany130]

Ahh, i see why its not working

this is the gamecope cmd

/usr/bin/gamescope --bypass-steam-resolution --prefer-output DP-2 --xwayland-count 2 --default-touch-mode 4 --hide-cursor-delay 3000 --fade-out-duration 200 --steam -R /run/user/1000/gamescope.cckWHj1/startup.socket -T /run/user/1000/gamescope.cckWHj1/stats.pipe

so there is no resolution in the gamescope command.

Apparently https://github.com/ChimeraOS/gamescope-session-steam (which is what all non steamos distros use to have a steame gamescope-session) gamescope grabs the Displays EDID and auto detects the resolution that way.

luckily it stores all that information in

───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: .config/gamescope/modes.cfg
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ LG Electronics LG TV SSCR2:3840x2160@120
───────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

But on steamos that won't work and we will either have to hard code the resolution like it was before, or I think the code from the above reply would work on steamos as I believe the resolution is passed as an argument there

something else I noticed is I am getting the flickering bug I mentioned before even if I comment out
GAMESCOPESESS=1 in

if grep -q "steam" <<< "$(pgrep -a "$GAMESCOPE")"; then
	writelog "INFO" "${FUNCNAME[0]} - Detected '$GAMESCOPE' running 'forced' - assuming we're running in Steam Game Mode"
	#GAMESCOPESESS=1

On the latest master I do not have this issue. I have no idea what I could of introduced that causes this flickering that commenting out GAMESCOPESESS=1 doesn't fix (all my changes SHOULD be behind GAMESCOPESESS=1 checks)

[zany130]

Ok done. I got all parts of this PR implemented; all that is left is to

• Fix the flickering bug introduced in this PR.
• Maybe do some scaling at high resolutions now its looking to small and its hard to read text 🤣
• Make the check for gamescope session less generic.(only checks if gamescope is running with steam, that doesn't always mean we are in Steam game mode)
• Make sure nothing is broken on steamos

for the last two I am probably going to have to install steamos on my deck (I have bazzite) I have an extra nvme drive so ill try swapping it out or maybe I can install steamos to a microsd card or USB.

I know you don't use STL on your deck @sonic2kk , but if you could (or anyone else with a deck on steamos) at least help with how the gamescope command looks like in steamos game mode that would be a tremendous help.

you can check that by SSHing into the deck when its in gamemode and running
pgrep -a gamescope

The problem is that the original check of

if grep -q "generate-drm-mode" <<< "$(pgrep -a "$GAMESCOPE")"; then

doesn't work on bazzite as the gamescope cmd there is

/usr/bin/gamescope --bypass-steam-resolution --prefer-output DP-2 --xwayland-count 2 --default-touch-mode 4 --hide-cursor-delay 3000 --fade-out-duration 200 --steam -R /run/user/1000/gamescope.cckWHj1/startup.socket -T /run/user/1000/gamescope.cckWHj1/stats.pipe

So I need to find something that is in both steamos and chimera/bazzite/halo game scope commands.
Preferably something more specific than just steam. Maybe xwayland-count would work, as I think that only works in embedded game scope sessions, AKA steam game mode? So I think we ran reasonably say that won't be present when running nested in the DE

As for the flicker bug introduced ... I have no clue what is causing it and much less how to fix it

I have no idea what it could be. I tried commenting out the steamdedeckt function call in main, which should pretty much disable all the changes I made. It will no longer check if we are in a game-scope session, and all of the changes I made are to parts of the code that rely on that being true.

That is the major hurdle to this getting merged. What good does improving gamescope session if you make it flicker in the process 😞

it is baffling as on master, it works fine, but on the PR, after the game launches, the screen starts flickering

PS: What I ended up doing about the Resolution detection in the game scope is having two paths for getting the resolution.

1. if we have a modes.cfg file in $HOME/.config/gamescope/ we grab the resolution from there (this will be true on all chimeraos like distros (bazzite, nobara, and I think holo os)
2. otherwise, grab the resolution from the gamescope arguments (I think steamos has the resolution it is running in on the gamescope command arguments (chimera does not)

[sonic2kk]

Sorry, I've been slacking on taking a look at this PR and that's my bad.

So the main things that need tested on this PR are:

1. What does the GameScope command look like on SteamOS, ultimately in order to determine how to find and set the GameScope resolution since it seems Bazzite doesn't set the resolution in the command. On the Desktop, if a user manually creates a session, this is fine since it is probably passed with the width and height flags.
2. Fixing the flicker issue you have described. I'll take a look at the code and see if I can find what might be causing the problem. This problem is exclusive to this PR and not on master, which sounds very strange. from a quick glance I am not sure what might have introduced it. My initial thought is that something is going wrong with setting the resolution, perhaps it is set incorrectly or there is some kind of window configuration behaviour that is different. Maybe places where the WINX and WINY values are set is messing things up? I'm not sure, maybe try hardcoding these cases back to 1280 and 800 just to see if that fixes the flickering as an initial test, but that's just a shot in the dark and a 3am thought :-)

[zany130]

Yup pretty much and no worries. I been really busy and haven't had much time to look into this. I should be able to do some steam deck testing next weekend.

As for the flicker bug not really sure what could be causing that. I had the same thought of checking the resolution stuff but it doesn't seem to be that..... The other thing I thought was maybe disabling the Mangoapp options as I think the flicker seems to be coming from the HUD I think

But I tried commenting out the relevant code. So not really sure.

Might not be able to look into this two much this week as I'm a bit busy , but I will try to find some time.