Fix games losing focus when using multiple monitors on Linux

󰃭 2025-11-05

Alright, let me give you the magic string right away:

gamescope --mangoapp -w 2560 -h 1440 -W 2560 -H 1440 --fullscreen --force-grab-cursor --adaptive-sync --backend=wayland -- env ENABLE_LAYER_MESA_ANTI_LAG=1 %command%

Put this in your Steam game launch options, adjusting the resolution and you should be good to go.

Just a couple more things:

  1. Don’t use the “stable” version of gamescope, use gamescope-git instead
  2. After installing gamescope, and every time you update it, run sudo setcap 'CAP_SYS_NICE=eip' $(which gamescope)
  3. Ensure you have variable refresh rate turned on on your monitor and DE/compositor

Now, if you’re still here you likely want to know what’s going on, and what the magical incantation above is doing.

What’s going on

So, for a while now some games have had issues with losing focus on Linux. In particular this is happening to me on GNOME (Wayland, considering X11 support has been dropped) with a monitor arrangement consisting of two 1440p monitors, horizontally arranged, with the primary one being to the right of the secondary one.

Note that similar issues seem to have been observed on Plasma, as well as various WM-like compositors, so it’s possible that it’s not a problem with GNOME itself.

The issue is sneaky, and it only seems to happen when rapidly moving the mouse, followed by clicking. You know, how one normally plays shooter games. By losing focus, I consistently lose in any direct confrontation, and consistently lose my patience.

I don’t know exactly when this started happening, nor why it’s happening, but it’s annoying and I’ve been trying to fix this on and off for a while.

Gamescope and stuttering

The common answer to similar issues is to just use gamescope with --force-grab-cursor, and while that works, I found that gamescope introduces problems of its own.

Notably, it seems that gamescope in nested mode (aka running it inside another compositor) introduces some anomalous stuttering and performance degradation in general.

Fixing this is multi-fold.

First, you need to run the setcap command above. This ensures that gamescope’s process is super non-nice, meaning it will have a very high scheduling priority.

Second, you want to turn on variable refresh rate/adaptive sync, in your monitor, in your DE AND in gamescope (the launch options above have the flag already set). This seems to make all the difference for me, but maybe if your monitor doesn’t support VRR at all you won’t be affected by this particular problem.

Third, you want to use the -git version of gamescope. It seems that the currently tagged version still doesn’t include many important fixes and patches.

And that should be it, gamescope should now behave properly and your game shouldn’t lose focus anymore.

A dumb alternative approach

This might sound obvious but turning off your secondary monitor(s) is an option and fixes the issue without any complicated setup. It’s dumb, it works, but it’s annoying and less than ideal. Still, worth mentioning.

Explaining the command

  • gamescope: well, that’s what we need to run
  • --mangoapp: optional, runs mangohud on top of the game; note that the usual MANGOHUD=1 works but is unsupported and may report inaccurate information, so just use this flag instead
  • -w 2560 -h 1440 -W 2560 -H 1440
    • -w and -h are the width and height your game should run at; gamescope will tell the game that this is your monitor’s resolution to force it to run at said maximum resolution
    • -W and -H are the width and height of the window that gamescope will render; this can be lower than your monitor resolution if you want your game to run windowed, or the same if you want to run it fullscreen
  • --fullscreen: optional, makes the game fullscreen
  • --force-grab-cursor: the reason we’re here, this captures the mouse so that it doesn’t escape gamescope’s window
  • --adaptive-sync: makes sure gamescope plays nicely with VRR monitors as explained above; disable this if you don’t have VRR
  • --backend=wayland: the backend gamescope will use to render; your choice on the matter seems to be between wayland and sdl, and it seems that at least for me wayland works best
  • --: this is some old school shell trickery to avoid parsing what’s after it as command line options, just put it in there
  • env ENABLE_LAYER_MESA_ANTI_LAG=1: optional, this turns on an implementation in mesa of AMD anti lag; this might improve latency for you, make things worse or do nothing at all
  • %command%: the command Steam uses to run your game

Alright, I’m putting this out there since there doesn’t seem to be anything out there that fully explains this problem. If you have any more insight on what’s going on, why it’s happening or if there is a way to fix it without resorting to gamescope, let me know via email or on fedi.


Enter your instance's address


More posts like this

RDNA3 Fan Control in Linux - Why are my GPU fans not spinning under load?

󰃭 2024-01-20 | #amdgpu #gpu #linux #radeon

I’ve recently upgraded my GPU from a 5700XT to a 7800XT, and of course using a new GPU close to launch on Linux would reveal some paper cuts.

Turns out my GPU fans weren’t spinning, even under load. It helps that it’s winter and I have some very effective case fans, but it didn’t really make sense that at 88°C junction temperature the fans wouldn’t spin.

Continue reading 


Giara is a reddit app for Linux

󰃭 2020-10-30 | #giara #gnome #gtk #linux #reddit #world

I am a quite avid reddit user. Like it or not, reddit is a very central place where communities for stuff that I care about tend to aggregate.

For the longest time, I have felt the need for a reddit app on my Linux desktop, and I waited and kept waiting for one that would finally allow me to break free of using the web version.

Continue reading 