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
Support for Gamemode #77
Comments
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. |
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? |
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:
|
Seems a bit strange the library would need systemd headers. I thought they were just for the daemon |
@Tomin1 Try passing it with-systemd=false with-daemon=false |
Also probably with-examples=false |
Please make a pull request, we can work on review and improvements there |
I suppose that to work you need to install game mode daemon on the host. Are there compatibility issues across versions? |
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 |
This is something that would be good for non steam games on Flathub. Should it go in the shared modules? |
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 |
@nanonyme Thank you for your insight. It was helpful although not enough here. I made a pull request. |
@nanonyme Gamemode activated automatically? |
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 |
I guess we could add easier variable for setting the preload still so you wouldn't need to know the paths |
I tried running a game with the launch options set to |
32bit or 64bit? Not some games ignore preload |
@nanonyme is that the exact launch option you use? I was wondering whether it shouldn’t be |
No. I don't think it even does anything on much on my machine as I have AMD CPU |
Might have broken when we removed full system bus access. Metadata only gives permissions to session bus which is probably wrong |
See #188 |
@jurf could you test if allowing system talk for the name fixes this? |
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? |
from a high-level perspective, the right approach to this kind of issue is:
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. |
@matthiasclasen There is no gamemode daemon on system bus, it uses session bus only. |
But uses a privileged helper ? |
Yes. |
@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". |
sounds like a case for "just don't do that" |
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. |
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. |
That might actually be a good thing whether or not it would be part of gamemode itself. |
(Also the downloading of updates, which is already an issue.) |
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 |
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? |
To swap is a an overkill, but some processes could indeed be shut down. |
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 |
@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 |
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. |
@mxre there was an earlier hint to flatpak ps code |
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... |
punching a hole in the Flatpak manifest to allow Steam (and games) to talk to the gamemode daemon directly
Can you explain it please?
|
Add |
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 |
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. |
It indeed needs xdg-desktop-portal version >= 1.4.0 on the host, which added the GameMode Portal. |
https://github.com/FeralInteractive/gamemode
The text was updated successfully, but these errors were encountered: