Snapshot of gaming on Linux

21. March 2025

Intro

A few days ago a blogger I follow told me Niri is the future. I was looking for a reason to switch from Hyprland for a while now because it feels like there's less things working than half a year ago. So I jumped at the opportunity and tried out Niri. This in turn forced me to yet again look at my graphics configuration so I could game with Niri, because even though wayland is the future and this year surely is the "Year of the Linux desktop", nothing ever just works out of the box.

But first what's wrong? The specific problems we try to solve today are all gaming related, as I would like to game without having to switch back to X11, or heaven forbid windows, every time.

Tearing support

Even though I am less than 10000 in rating in CS2 I like to imagine myself as some kind of prodigy, just having some bad luck when aiming. And as such a high level player I need frames as fast as possible. To get them what I want is support for tearing page flips. Sadly this is not yet possible in Niri there is an open issue, but it's dependent on a pull request to the underlying library, which seems dormant.

So for CS2 I'll still have to switch back to good old X11 using i3, but at least finding this solution was rather straightforward. For most other games however this isn't such a deal breaker as game speed isn't as important. My farm in Stardew Valley will survive if I don't harvest my crops frame perfect.

Tabbing out

Sometimes I would like to do something in another window while having the game running, and when I switch back into the game I would like to continue playing. Since that is such a unheard of usage pattern, it doesn't just work. I've tested Anno 1800 and Baldur's Gate 3 and both show black screens after moving focus back to the game.

The internet tells me gamescope might be a solution. Gamescope is a 'micro-compositor' from valve for use on the steamdeck, that can also be run as a nested session inside a regular desktop, where it is sandboxes the application from the rest of the system, especially from window or desktop events. It also allows the process to re nice itself, something I currently achieve using gamemode, but I'm always for less dependencies. So in typical NixOS fashion I enable the respective options, read the arch wiki article on how to use it and try it out.

Gamescope Session

NixOS has both programs.gamescope options and programs.steam.gamescopeSession options. The first enables gamescope as a standalone program, while the second one adds a steam-session program that starts a gamescope session containing steam. As this runs steam as the only window in the compositor it automatically enables Big Picture Mode and controller controls 🤔. While this sounds great for couch gaming its not really what I want on my desktop.

One other use case where the 'embedded' session might be a good idea is single player gaming, when I don't need other windows such as TeamSpeak or a browser open. Gamescope seems to support all desired wayland extensions for gaming, with a focus on fast frame delivery, while being very minimalist and using limited resources. Now I just need to learn Counter Strike with a controller.

Gamescope Runner

Anyway the options we actually want to set for our use case of running programs with gamescope, while in a wayland session are programs.gamescope.enable and programs.gamescope.capSysNice. These add gamescope to the environment and allow it to re nice itself. Then we can set the launch options for our game of choice to gamescope --rt -W 2560 -H 1440 -- %command%, which should start the game inside gamescope.

Sadly it fails starting anything at all.

After searching through the insanely cluttered and unstructured steam logs, I found the error message: failed to inherit capabilities: Operation not permitted. Looking for this error in the nixpkgs issues shows issue #351516. Basically since steam runs inside a FHSEnv it is not possible for child programs to be allowed to re nice itself. Well, while annoying there are other solutions for giving games a lower nice score, gamemode or ananicy are two popular examples, and that wasn't even the reason I wanted gamescope, so for now I'll just have to disable capSysNice.

This finally allows games to start with gamemode. Trying out Anno it seems to work for a while, tabbing out, moving or resizing the window all work flawlessly.

However the cursor is not rendered completely, instead it is cut in half and only the left side is visible. Turns out this is a known driver bug in NVIDIA, which only recently got fixed, so recently I didn't have the patch yet. So upgrading my system it is. Surely then everything will work.

F*** NVIDIA

First of all, let's take a step back. What do you mean it's 2025 and there is a known bug where your mousecursor, the main way to interact with your computer since the 80s, isn't rendered correctly?

But I digress so let's update drivers, shutdown system, restart and ... never reach the login screen? Well. Shite.

Linux rendering comprises a very complicated set of libraries, interfaces and drivers, which I also don't fully understand so we will ignore most of it and only focus on the important part here: fbdev.

fbdev

At first there were framebuffers, shorthand fbdev. This is a simple device agnostic API giving userspace access to a framebuffer to show its output. Today this is still used for simple deployments, when one wants to skip the overhead and complexity of the newer APIs. The only place where you may actively encounter output driven by fbdev is in the Linux console, the text only screen you get when not using a display manager.

The new system, which drivers implement today is called DRM, Direct Rendering Manager, but for backwards compatibility and supporting setups, such as mine, a lot of drivers still expose a framebuffer device based upon their DRM implementation. So does NVIDIA. While it used to be default disabled, as of driver 570 NVIDIA decided to start default enabling the nvidia-drm.fbdev option. Which for some reason broke console rendering completely for me. As I am using the console to login and start my compositor this made it impossible to boot. As long as any non DisplayPort monitor was plugged in while booting, the NVIDIA fbdev implementation completely froze the screen as soon as it took over the output.

Sadly I have no idea why that is. My GPU isn't the newest, a GTX 1080, and as such isn't supported by their new open driver, forcing me to still be using their closed source driver. But still default enabling an option that completely breaks by computer feels like a dick move to me.

Anyway let's take a step back we got kinda sidetracked here, do we even want the fbdev implementation?

Well it's hard to say. While I don't really care about my console being high res and GPU accelerated, Hyprland does suggest enabling it for NVIDIA cards and I do hope NVIDIA didn't just default enable it for fun, they must've had a reason to think it will improve setups. But on the other hand I haven't needed it so far.

The optimal solution to this would be using a display manager, but the quick solution for now is just disabling fbdev, by setting kernel param nvidia-drm.fbdev to 0.

Missing textures

Being able to boot again, I got back into Anno, played for an hour and had a great time. Until the houses started to disappear. While my friends very much still see them on my screen there was only ground, or sometimes just the void. Seems like something in the renderer is broken and some surfaces aren't displayed. At first I thought gamescope might be at fault but it also happens when not in a gamescope window, just less often.

I have no idea what's happening here, I'm not even sure it's actually NVIDIA's fault, might also be proton. Good thing I don't reach this point most of the time because the game crashes before the renderer starts missing textures.

Crashing Anno

Turns out Anno quite likes to crash:

Multiplayer

Looking through reddit it seems like Anno has a somewhat finicky multiplayer implementation, that sometimes has problems with syncing. While that is annoying as is, on windows it just shows a error message and reloads, maybe loosing some progress. On Linux however it completely breaks the save, in a way that even loading it in any way crashes the game. Doesn't matter if I'm on X, Hyprland or Niri. That save is completely unplayable for me from now on. Not even deleting it and getting it from a friend again fixes it.

Yet again I have neither an explanation, nor a solution to give, apart from switching to windows for Anno 1800 Multiplayer. I couldn't get it to work.

VRAM

At least singleplayer might work, right? 😭 This is where we truly get back to f*** NVIDIA.

After playing singleplayer for around 15 minutes the game will crash. And not just exit and done, it takes things with it. Steam becomes unresponsive, sometimes my browser stops rendering for a while, rarely the whole desktop just yeets itself. At least this time the system log shows an error I can search for.

This brings me to this NVIDIA forum thread. TL DR: The NVIDIA Linux driver, as the only driver in existence has a problem with overfilling the VRAM. Instead of spilling over into system memory, or doing literally anything else, it will just stop functioning correctly and crash a bunch of rendering processes. Great.

Interestingly this happens on Niri on its own, while on X and Hyprland the game seems to limit itself to not overfill the VRAM, and you only get it to crash by suddenly opening another program that uses enough memory to fill my GPU. No idea what kind of voodoo X and Hyprland are doing, but it's still far from optimal as I would like to be able to open a stream, without it crashing my games in the background.

Solutions: None that I know. Buy more VRAM I guess?

Resolution

I guess gaming on Linux is still not where I wish it was. While most games work most of the time, these small problems add up. I wish I could just start a game without suddenly having to learn about Linux framebuffers.

Even more annoyingly it's a never ending search for what's even at fault this time again. Is it proton? Is it wayland? Is it NVIDIA? Is it my Compositor? Is it NixOs? All of them have noticeable bugs and quirks where you can never be sure it isn't their fault. And thus every time something doesn't work you're stuck trying a hundred different setups, looking through 50 logs, reading 200 reddit posts, trying a bunch of different remedies, most feeling more like superstitions than actual solutions. Only to be left with no real answer to what's wrong or how to fix it.

And I know a bunch of it is partly fault, I am using a weird OS, I am using an 7 year old graphics card and I am using niche programs and setups. But still sometimes I would just like to be able to play some games.

See you in 2 months when I yet again talk myself into thinking gaming on Linux might just work good enough.

https://blog.lel.lol/blog/atom.xml