You fire up a demanding title on Fedora and the frame rate stutters
The GPU is maxed out, but the CPU is playing it safe. You read about GameMode on a forum, install it, and wonder why nothing changes. The service is running, but your game never talks to it. You are missing the handshake between the application and the daemon.
What's actually happening
GameMode is not a global performance toggle. It is a D-Bus daemon that listens for explicit requests from applications. When a game asks for it, the daemon temporarily switches the CPU frequency governor to performance mode, raises the process priority, and can adjust GPU power limits. Fedora ships with conservative power defaults to keep laptops cool and desktops quiet. The power-profiles-daemon handles those defaults. GameMode overrides them only while the target process is alive. The daemon does not guess which programs need boosting. It waits for a signal.
The architecture relies on systemd socket activation. The daemon does not sit in memory waiting for work. systemd starts it the moment a client connects to the D-Bus socket. When the last client disconnects, the daemon exits. This design keeps idle resource usage near zero. It also means you must enable the socket, not the service. Enabling the service directly defeats the purpose and leaves an idle process consuming memory.
The D-Bus interface is straightforward. The client sends a Start() method call. The daemon validates the request against the configuration file. If the executable is allowed, the daemon applies the governor switch and renice operation. When the client process exits, the daemon receives a Stop() signal and restores the previous power profile. The entire cycle happens in milliseconds. You will not see a terminal prompt or a GUI dialog. The boost is silent.
The fix and configuration
Install the package and activate the socket. Fedora handles the D-Bus policy files automatically. The package manager places the default configuration in /etc/gamemode.ini.
sudo dnf install gamemode
# WHY: pulls the daemon, client wrapper, and default configuration files
sudo systemctl enable --now gamemoded.socket
# WHY: registers the D-Bus socket for activation. systemd will start the daemon on demand.
Verify the socket is listening before you touch any configuration.
systemctl status gamemoded.socket
# WHY: confirms the socket is active and ready to accept D-Bus connections
Configuration lives in two places. The system-wide file sits at /etc/gamemode.ini. Your user-specific overrides go in ~/.config/gamemode.ini. The user file takes precedence. Never edit files in /usr/lib/. Package updates will overwrite them. Edit /etc/ or ~/.config/.
The default configuration already enables CPU frequency scaling and process priority boosts. You only need to modify it if you want to restrict which executables can trigger the mode, or if you want to disable automatic GPU adjustments.
[general]
# WHY: restricts which binaries are allowed to request GameMode. Leave empty to allow any process.
allowed_executables = /usr/bin/steam,/opt/games/mytitle
# WHY: enables the CPU governor switch. Fedora defaults to powersave. This forces performance while active.
cpu_inject = 1
# WHY: sets the process nice value. Negative numbers increase priority. -10 is safe for desktop use.
renice = -10
Launch your game through the gamemoderun wrapper. The wrapper connects to the D-Bus socket, requests the boost, executes your command, and tears down the boost when the process exits.
gamemoderun /path/to/your/game/executable
# WHY: wraps the execution. The daemon applies governor and priority changes only for this process tree.
Steam and Proton handle this automatically if you enable the option in the client settings. The wrapper is for native Linux titles or standalone launchers. Steam users should enable the GameMode toggle in the Steam settings menu under Performance. The client will inject the D-Bus call before launching the Proton prefix.
Verify it worked
Confirm the governor changed and the process priority shifted. Open a second terminal while the game is running.
cpupower frequency-info
# WHY: shows the current CPU frequency governor. Look for "performance" under the active policy.
Check the process priority directly. Replace the PID with your game's actual process ID.
ps -o pid,comm,nice -p <PID>
# WHY: displays the nice value. A value of -10 confirms the priority boost applied correctly.
Check the daemon logs if the governor did not switch. The logs show exactly which settings were applied and whether the request was accepted.
journalctl -xeu gamemoded.service
# WHY: filters the journal for the daemon. The x flag adds explanatory context. The e flag jumps to recent entries.
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and what the error looks like
The most common failure is a mismatched executable path. GameMode compares the requested binary against the allowed_executables list using exact string matching. Symlinks break the check. Resolve the symlink first.
readlink -f /usr/bin/your-game
# WHY: prints the absolute path. Use this exact string in the configuration file.
Steam users often see the boost fail because Proton launches a nested process tree. The parent process requests GameMode, but the actual rendering happens inside a child process. GameMode inherits the boost across the process group by default. If it does not, you need to enable process group tracking in the configuration.
[general]
# WHY: ensures the boost applies to child processes spawned by the game or Proton wrapper.
inherit = 1
SELinux denials appear when the daemon tries to write to restricted kernel interfaces. Fedora enforces mandatory access controls by default. Do not disable SELinux. Read the denial summary first.
journalctl -t setroubleshoot
# WHY: filters for SELinux alert messages. The one-line summary tells you exactly which policy module needs adjustment.
If you see Error: Failed to connect to D-Bus session bus when running gamemoderun, your desktop session is missing the D-Bus environment variables. Restart your graphical session. The socket activation will recover automatically.
Another frequent issue is the power-profiles-daemon fighting GameMode. Both tools try to control the CPU governor. Fedora's power daemon will revert the governor back to powersave or balanced if it detects a change outside its own policy. You can tell the power daemon to ignore specific applications by adding them to the ignore list, or you can rely on GameMode's cpu_inject flag which uses the cpufreq sysfs interface directly. The direct sysfs write bypasses the power daemon's polling loop.
If the daemon refuses to start and prints Failed to start GameMode daemon, check the socket unit first. The service unit is a dependency of the socket. If the socket is masked or failed, the service will never launch. Run systemctl unmask gamemoded.socket and try again.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use GameMode when you want automatic, per-session CPU and priority boosts that activate only while a specific game runs. Use tuned profiles when you need system-wide performance tuning for servers or continuous workloads. Use cpupower frequency-set when you want a manual, persistent governor change that survives reboots. Use systemd-run --scope when you need temporary resource isolation without installing extra packages. Stay on the default Fedora power settings if you only play lightweight titles or prioritize battery life.