Gaming

What’s set up for games, and how to check it.

The launchers

Installed from Flathub on the first boot with a network. Ordinary Flatpaks: removed ones stay removed.

App	Flatpak ID
Steam	`com.valvesoftware.Steam`
Heroic	`com.heroicgameslauncher.hgl`
Faugus Launcher	`io.github.Faugus.faugus-launcher`
Bottles	`com.usebottles.bottles`
ProtonPlus	`com.vysp3r.ProtonPlus`
protontricks	`com.github.Matoking.protontricks`
MangoHud (the Vulkan layer)	`org.freedesktop.Platform.VulkanLayer.MangoHud`

In the image: gamescope, gamemode, MangoHud, and controller/headset udev rules (steam-devices).

Launch options

gg runs a game through gamescale and gamemode. ggm also turns on MangoHud. In Steam, set a game’s Launch Options to one of:

The Steam Flatpak needs no setup. At every boot pulsar-steam-grants.service lets Steam’s sandbox run the image’s own gg, ggm and gamescale, so they update with the image.

Other Flatpak launchers need pulsar setup gamescale --platform <name> once. It puts gg and ggm in ~/.local/bin beside gamescale, and leaves alone any gg or ggm of your own already there. If you ran it for Steam on an older image, run pulsar setup gamescale again: it points Steam at the image’s copies and removes old copies that match them.

gamemode

/etc/gamemode.ini differs from the defaults in two ways:

igpu_power_threshold=-1: stops gamemode dropping the CPU to powersave mid-game on dual-GPU laptops (it misreads the integrated GPU’s power).
renice=10: needs the gamemode group; the first boot adds every existing account.

Group changes apply at your next login; pulsar doctor gamemode tells you if you need to log out.

Proton and the kernel

ntsync loads at boot and /dev/ntsync is given to the seat user, so Proton uses kernel sync instead of esync/fsync.

Kernel settings:

Setting	Why
`kernel.split_lock_mitigate = 0`	The kernel stalls a process about 10 ms for every split lock, as a deterrent. Several Windows games split-lock constantly and turn into a slideshow under it.
`vm.max_map_count = 2147483642`	Proton games with huge address-space appetites exhaust Fedora’s default and crash.
`transparent_hugepage/defrag = defer+madvise`	Hugepage defragmentation is deferred to the background instead of stalling the thread that faulted, which may be the one drawing your frame. Only memory a program explicitly asked to be hugepage-backed still waits for it.
`vm.compaction_proactiveness = 0`	No compaction on a timer. Compaction when memory is actually wanted is untouched.
`vm.min_free_kbytes = 524288`	512 MB of headroom, so a game that allocates hard gets background reclaim instead of reclaiming mid-frame itself.

The scheduler is scx_bpfland where the kernel can load it (it places threads better on hybrid P/E-core CPUs). Otherwise stock EEVDF runs and pulsar doctor says so.

NVIDIA and Flatpak games

Flatpak apps need a GL extension matching the NVIDIA driver, read at app start.

pulsar-gl-nvidia.service installs it for the running driver at boot, and for the next driver when an update is staged.
An app started before its extension arrived renders on the integrated GPU (often a black window). Pulsar notifies: Restart Steam to use the NVIDIA GPU. Quit Steam fully and reopen it.
The Steam client’s own window runs with the NVIDIA driver’s vsync off, through a driver profile matched on its process name, so it draws at the display’s refresh rate instead of stalling. Games Steam starts keep their own vsync setting.

The MangoHud Flatpak layer only works on the matching runtime branch; when Steam changes runtime the overlay silently disappears. pulsar doctor mangohud checks this.

Loading screens

GNOME’s “not responding” check waits 20 seconds instead of 5, and is suspended entirely while a game runs under gamemode, so loading screens don’t trigger it.

Checking it

Native resolution under fractional scaling: gamescale. All checks: Troubleshooting.

Written with help from AI and reviewed by a person before publishing. Spotted a mistake? Let us know.