Linux gaming's next leap isn't more FPS, it's a working Wayland overlay

Published Sep 12, 2026, 1:30 PM EDT His love of PCs and their components was born out of trying to squeeze every ounce of performance out of the family computer. Tinkering with his own build at age 10 turned into building PCs for friends and family, fostering a passion that would ultimately take shape as a career path. Besides being the first call for tech support for those close to him, Ty is a computer science student, with his focus being cloud computing and networking. He also competed in semi-pro Counter-Strike for 8 years, making him intimately familiar with everything to do with peripherals. For most of the last couple of decades, Linux gamers have been focused on compatibility. With each passing Proton release and DXVK flashpoint, you can actually count the games that don't work on Linux instead of it being the other way around. Performance was another hurdle, and the gap between your distro of choice and Windows has shrunk year over year to the point where it really just depends on the game. We've now reached the point where the next mountain to climb is a lot smaller, but far more visible in everyday use. When you press Shift-Tab to open the Steam overlay or another keyboard shortcut for some other in-game overlay of your choice, we just expect it to open, and we sort of take that for granted on Windows. It's not a monumental issue, but those overlays are a real problem on Linux. The overlay is integral to gaming on Steam It's responsible for a lot more than you might expect When we think of the Steam overlay specifically, we think about things like screenshots, friends lists and communication features, a performance overlay, maybe a web browser. These are the kinds of things that are nice to have, but don't exactly scream "integral." The truth is, the Steam overlay is responsible for a lot, namely Steam Input. GloriousEggroll, developer of Nobara and GE-Proton, spells it out quite plainly in some recent patch notes: the Steam overlay doesn't work under wine-wayland, and consequently, neither does Steam Input, because Steam Input requires the overlay for assigning profiles. Once you lose the overlay, controller remapping goes with it, and therein lies the problem. This is an issue people are having right now, and it's affecting inputs in that exact way. Depending on the combination of game, type of Steam install (Flatpak, native binary or otherwise), and input device being used, there can be so many different issues that can crop up, and it has to do with how Wayland treats a game session. If you want a feel for how widespread this is, just take a scroll through the issues and purported fixes people have for this in Valve's steam-for-linux repo. The problem is older than Wayland's popularity This has been a long-standing issue The Steam overlay directly relies upon GLX and X WSI for OpenGL and Vulkan respectively, and this causes some issues with the way the overlay needs to be drawn in Wayland. For OpenGL, the piece that connects a game's rendered frames to a window on X11 is called GLX, and it's tied to X11. Wayland applications use EGL instead, which does the same job without dragging X11 along with it. Steam's overlay hooks the GLX calls and not the EGL ones, so an OpenGL game presenting through EGL simply never sees it. Vulkan has a similar split, because Steam's Vulkan layer wraps the X11 extension needed to draw an overlay but not the Wayland one. This has been an issue for a pretty long time. Valve's steam-for-linux repo currently has an open issue for adding Wayland support to the Steam overlay that has been active since 2021—over five years ago. There are workarounds, but they have a price Sometimes it's not worth it Workarounds for this overlay mess do exist, but they all come with a cost. Native Linux games that lose their overlay in a Wayland session can be launched with "SDL_VIDEODRIVER=x11", which fixes it by turning the game back into an X11 client. Games under Proton can, of course, be wrapped in gamescope, which can get the overlay back but adds a nested compositor between you and your display, and needs its own configuration before the overlay behaves. If you're just after a framerate counter, you should probably just install MangoHud and accept your fate. MangoHud specifically is a good example of how overlays can dodge this entire mess: it almost always works because it's an implicit Vulkan layer, drawn inside the game's own render pass rather than asking a compositor for a surface. This dodges the entire windowing conversation, but unfortunately, not all overlays behave this way. Every fix for one of the others can cause you to drop HDR, sacrifice frame pacing or fractional scaling, or even just the native session that you're on Wayland for in the first place. It's a problem that's actively being addressed The good news is, in spite of there being active issues open for half a decade, there is some serious work being done in the overlay department. GE-Proton11-6 added Steam overlay support under Wine-Wayland, moved Vulkan interception into a standalone vkroots implicit Vulkan layer, pulled overlay-specific code out of winewayland.drv, and relocated the shared focus and input bridge so it works with native Vulkan and native OpenGL. It's the community fork, so users on other Proton builds are left out, but as Wayland continues to be the preferred display protocol across the most popular distros, official fixes will come down the chain eventually.