Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Gamemode #77

Closed
LeandroStanger opened this issue Apr 17, 2018 · 84 comments · Fixed by flatpak/xdg-desktop-portal#314
Closed

Support for Gamemode #77

LeandroStanger opened this issue Apr 17, 2018 · 84 comments · Fixed by flatpak/xdg-desktop-portal#314

Comments

@LeandroStanger
Copy link
Contributor

https://github.com/FeralInteractive/gamemode

@nanonyme
Copy link
Collaborator

I'm not sure this is reasonable to do on Flatpak-level as it doesn't know when Steam has launched a game. This seems more like a thing that should be in Steam itself.

@nanonyme
Copy link
Collaborator

I guess something that could be done with this is to ship libgamemode in the app and expose gamemode DBus to the container so the daemon gets to run in host and games that grow integration could take it into use. @TingPing opinions?

@Tomin1
Copy link
Contributor

Tomin1 commented Aug 24, 2018

I think that's exactly what should be done. I already tried to add it but I'm missing libsystemd headers and I don't know what would be a good way to add them. I suppose our runtime/platform/whatever doesn't include them.

This is what I have so far (apply to current master aka aa14866), it doesn't build yet:

diff --git a/com.valvesoftware.Steam.json b/com.valvesoftware.Steam.json
index 287c594..33b30b4 100644
--- a/com.valvesoftware.Steam.json
+++ b/com.valvesoftware.Steam.json
@@ -15,6 +15,7 @@
         "--talk-name=org.gnome.SettingsDaemon",
         "--talk-name=org.freedesktop.NetworkManager",
         "--talk-name=org.kde.StatusNotifierWatcher",
+        "--talk-name=com.feralinteractive.GameMode",
         "--filesystem=xdg-music:ro",
         "--device=all",
         "--allow=multiarch",
@@ -68,6 +69,14 @@
 		"sha256": "c1cfd4e1d4d708c031d60801e527abc9b6d34b85f2ffa2cadd21f75ff38151cd"
 	    }]
 	},
+	{
+	    "name": "gamemode",
+	    "sources": [{
+	        "type": "git",
+	        "url": "https://github.com/FeralInteractive/gamemode.git",
+	        "tag": "1.2"
+	    }]
+	},
 	{
 	    "name": "steam_wrapper",
 	    "buildsystem": "simple",

@nanonyme
Copy link
Collaborator

Seems a bit strange the library would need systemd headers. I thought they were just for the daemon

@nanonyme
Copy link
Collaborator

@Tomin1 Try passing it with-systemd=false with-daemon=false

@nanonyme
Copy link
Collaborator

Also probably with-examples=false

@nanonyme
Copy link
Collaborator

Please make a pull request, we can work on review and improvements there

@valentindavid
Copy link
Contributor

I suppose that to work you need to install game mode daemon on the host. Are there compatibility issues across versions?

@nanonyme
Copy link
Collaborator

They haven't even done any releases yet so who knows. But yes, that's the way this feature is going to need to work so the daemon can run outside sandbox

@valentindavid
Copy link
Contributor

This is something that would be good for non steam games on Flathub. Should it go in the shared modules?

@nanonyme
Copy link
Collaborator

Imo let's do it right this time and only put it to shared modules once we have proof it works with the build system. It's easier to test build embedded modules

@Tomin1
Copy link
Contributor

Tomin1 commented Aug 25, 2018

@nanonyme Thank you for your insight. It was helpful although not enough here. I made a pull request.

@LeandroStanger
Copy link
Contributor Author

@nanonyme Gamemode activated automatically?

@nanonyme
Copy link
Collaborator

No, you can do the described LD_PRELOAD trick manually if you need it. The library is under /app/lib. Caveat is we cannot currently provide it at all for 32bit games due to build system limitations. Note that the preload trick will not work for all games anyway

@nanonyme
Copy link
Collaborator

I guess we could add easier variable for setting the preload still so you wouldn't need to know the paths

@jurf
Copy link
Member

jurf commented Aug 29, 2018

I tried running a game with the launch options set to LD_PRELOAD=$LD_PRELOAD:/usr/\$LIB/libgamemodeauto.so.0 %command%, as described in FeralInteractive/gamemode, but it didn’t work.

@nanonyme
Copy link
Collaborator

nanonyme commented Aug 29, 2018

32bit or 64bit? Not some games ignore preload

@jurf
Copy link
Member

jurf commented Aug 29, 2018

@nanonyme is that the exact launch option you use? I was wondering whether it shouldn’t be LD_PRELOAD=$LD_PRELOAD:/app/lib/libgamemodeauto.so.0 %command% for Flatpak. Also, do you have a game where you can confirm it works so I can try too?

@nanonyme
Copy link
Collaborator

No. I don't think it even does anything on much on my machine as I have AMD CPU

@nanonyme nanonyme reopened this Aug 29, 2018
@nanonyme
Copy link
Collaborator

Might have broken when we removed full system bus access. Metadata only gives permissions to session bus which is probably wrong

@nanonyme
Copy link
Collaborator

See #188

@nanonyme
Copy link
Collaborator

@jurf could you test if allowing system talk for the name fixes this?

nanonyme added a commit that referenced this issue Aug 29, 2018
@mxre
Copy link

mxre commented Aug 30, 2018

I've a general question on using gamemode from inside a flatpak sandbox.

gamemode uses dbus to communicate with the service gamemoded (running outside the sandbox). The releveant DBus call is com.feralinteractive.GameMode.RegisterGame/UnregisterGame this call needs as an argument the PID of the Program (libgamemodeauto.so uses getpid()) and the service uses this PID to set niceness and io_sched.

Now PIDs from inside the sandbox are useless outside, so how should gamemode work with flatpak?

@matthiasclasen
Copy link

matthiasclasen commented Sep 24, 2018

from a high-level perspective, the right approach to this kind of issue is:

  • write a portal that provides a 'gamemode' api on the session bus for sandboxed apps and uses the gamemode library to forward requests to the gamemode daemon on the system bus
  • ship a patched gamemode library in the sandbox that talks to the portal instead of the gamemode daemon

Ideally, the library patch can go upstream and transparently do the right thing, by looking for /.flatpak-info.

If the gamemode daemon needs the pid of the game process to do process-level changes, there is some prior art on pid translation in the flatpak ps code.

Note that this comment is purely about making gamemode work in flatpaks. I don't know if the steam launcher adds extra complications to this.

@gasinvein
Copy link
Contributor

gasinvein commented Sep 24, 2018

@matthiasclasen There is no gamemode daemon on system bus, it uses session bus only.

@matthiasclasen
Copy link

But uses a privileged helper ?

@gasinvein
Copy link
Contributor

Yes.

@nanonyme
Copy link
Collaborator

@matthiasclasen Steam launcher shouldn't be giving that many problems for explicit access of gamemode. These weird quirks are mostly about the "things don't actually have gamemode support so we're going to preload a random library into these executables and pretend they do".

@matthiasclasen
Copy link

sounds like a case for "just don't do that"

@nanonyme
Copy link
Collaborator

That sounds fair. That means though that this gamemode thing would probably at very least be sold to Valve, preferably game vendors as well for this feature to be at all doable.

@jurf
Copy link
Member

jurf commented Sep 29, 2018

Speaking of GameMode, it might be useful to somehow tell GNOME Software not to do background updates while playing a game, now that automatic updates are enabled in 3.30.

@nanonyme
Copy link
Collaborator

That might actually be a good thing whether or not it would be part of gamemode itself.

@jurf
Copy link
Member

jurf commented Sep 30, 2018

(Also the downloading of updates, which is already an issue.)

@nanonyme
Copy link
Collaborator

nanonyme commented Oct 1, 2018

Can you please raise that with Gnome? They would probably need to provide an interface to temporarily suspend updates for what you described to work. Probably a secure one so unprivileged users can't abuse it

@jurf
Copy link
Member

jurf commented Oct 1, 2018

Done.

@pablodav
Copy link
Contributor

pablodav commented Oct 1, 2018

Good to see this discussion.

Just thinking in others things that can make issues when gaming: tracker should not do indexing operations during users is in "game mode", as it also uses disk IO and lot of CPU sometimes. Not sure if tracker already has some tweaks to not affect the user, but I see it using lot of CPU sometimes when gnome starts.

Probably best behaviour in game-mode for gnome-software and tracker:

Just sleep the processes for tracker and gnome-software when launching steam from flatpak, so also the processes could go to swap if required instead of keep using RAM/CPU/IO? could be something easy to do from steamwrapper?

@jurf
Copy link
Member

jurf commented Oct 1, 2018

To swap is a an overkill, but some processes could indeed be shut down.

@nanonyme
Copy link
Collaborator

nanonyme commented Oct 2, 2018

Kernel usually makes sure memory is properly swapped where not pinned for some reason. You just need to make sure you idle and everything will be fine

@nanonyme
Copy link
Collaborator

nanonyme commented Oct 5, 2018

@mathiasclasen your suggestion sounds reasonable. Downside is I at least have zero knowledge on writing portals. Currently using upstream library means libsystemd dependency to all parties using it. I don't know whether this constitutes as overkill since it's just a simple API for doing a couple of Dbus calls given I have never done Dbus with so low-level languages

@mxre
Copy link

mxre commented Oct 7, 2018

IMHO the systemd dependency is easily avoided I wrote a version of gamemodeauto.so without it (https://github.com/mxre/gamemode). I think upstream libgamemode devs where to lazy to actually use dbus directly. (It's pretty easy)

I think using a portal ist the best way to map the sandboxed PIDs to system PIDs.
On the system the sandboxed PIDs can be inspected in /proc//status as NSpid
but i found no other way to find the right NSpid (corresponding to the right namespace) unless I iterate over all running processes.

@nanonyme
Copy link
Collaborator

nanonyme commented Oct 7, 2018

@mxre there was an earlier hint to flatpak ps code

@hadess
Copy link

hadess commented Apr 11, 2019

We discussed gamemode integration in #flatpak today, and @matthiasclasen and I agreed that the easiest way to add gamemode support might be to modify the daemon to track D-Bus clients instead of PIDs, removing the need for a portal to do that translation, and punching a hole in the Flatpak manifest to allow Steam (and games) to talk to the gamemode daemon directly.

Making sure the gamemode versions and APIs inside and outside the sandbox match and track the same thing is going to be more complicated though...

@gasinvein
Copy link
Contributor

gasinvein commented Apr 11, 2019 via email

@hadess
Copy link

hadess commented Apr 11, 2019

Can you explain it please?

Add --system-talk-name= com.feralinteractive.GameMode to the finish-args

@hadess
Copy link

hadess commented Apr 11, 2019

We discussed gamemode integration in #flatpak today, and @matthiasclasen and I agreed that the easiest way to add gamemode support might be to modify the daemon to track D-Bus clients instead of PIDs, removing the need for a portal to do that translation, and punching a hole in the Flatpak manifest to allow Steam (and games) to talk to the gamemode daemon directly.

And talking some more with @gicmo, the PID is really baked into the API, so the solution might be to write a portal after all. As this is very specific to a service that has a, shall we say, limited shelf life (ideally, gamemode wouldn't need to exist, but this isn't how things worked out), we thought it best not to add it directly in xdg-desktop-portal, but it could be implemented as a separate portal, as a stand-alone daemon, or inside the gamemode daemon itself, owning the org.freedesktop.Portal.gamemode name.

@nanonyme
Copy link
Collaborator

nanonyme commented Jul 12, 2019

Note this now requires quite new xdg-desktop-portal to work and only works in beta branch of this app. @gicmo can probably provide some details about former.

@gicmo
Copy link
Contributor

gicmo commented Jul 13, 2019

It indeed needs xdg-desktop-portal version >= 1.4.0 on the host, which added the GameMode Portal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.