Conflicts with gamemode (and foreground apps getting background priorities)

[robobenklein]

Noticed that a few things (mostly games) were running slightly poorer than they used to, like minor stutters or vastly higher minimum/99% frame times. Tried to apply gamemoderun but quickly found that their priority was getting lowered after the fact.

Gamemode keeps track of every process it's active for, and it can be asked over DBUS about which processes it has registered, e.g.

# dbus-send --session --print-reply --dest=com.feralinteractive.GameMode --type=method_call /com/feralinteractive/GameMode com.feralinteractive.GameMode.QueryStatusByPID int32:$PPID int32:1155695
method return time=1654503762.757012 sender=:1.393 -> destination=:1.12203 serial=11575 reply_serial=2
   int32 2

(send own PID, pid of process to check if gamemode is active for, returns 1 when gamemode is active, but not for that PID, 2 when that proc is registered under gamemode, and -1 if not active)

I think S76-scheduler should avoid setting priorities on processes already managed by gamemode.

I am not sure why, but even while an application/game is in focus, S76-scheduler assigns it a background nice 5 even though it's the foreground application. This is 100% reproducible using a steam game with Proton configured to use gamemode. In this sense, I would consider having the foreground application/game's priority lowered a bug.

A potentially easier workaround would be to just disable the S76-scheduler while gamemode is active, but that seems like a somewhat poorer solution if DBUS communication is possible. (Though it's what I will recommend to fellow gamers until a better option is available)

[mmstick]

It sounds like the main issue is that pop-shell didn't assign foreground status to this game. Is that true? With the log level set to DEBUG in the extension prefs for pop-shell, you can track assignments with journalctl -o cat -f /usr/bin/gnome-shell | grep 'setting priority'.

[robobenklein]

I will check to see if proton might be causing something strange with foreground procs, but this also applies to non-foreground apps run with gamemode, such as SC-Controller. Not really sure how to write a rule for that though, since it's process name is just python3.

[robobenklein]

The issues with foreground detection appear to be centered around me launching applications via terminals most of the time. An example is Discord, which I always launch through firejail from a terminal, when any terminal is focused, Discord gets a foreground priority even though it's not even on this desktop.

I'm using Tilix, so all terminals share the same parent process, thus every application I've started out of any Tilix terminal will get the foreground priority when any Tilix window is focused.

I think starting apps from terminals is certainly not the norm, so I might just disable the foreground detection for myself, but I think this issue would then extend into running other things from terminals like stress or any compiler that isn't on the list. I'll open a separate issue for this.

I'd still like gamemoderun to be respected for non-GUI apps though, like in SC-controller's case the main GUI disappears and the daemon still needs priority in the background to process user input in realtime.

[mmstick]

If a process is owned by a terminal, then focusing the terminal will give its child processes a foreground priority. That is expected. Likewise, focusing a web browser window will give foreground priority to all the web processes it owns, such as how Chromium gives each tab its own child process attached to the foreground process that owns the window.