GNOME 50 finally fixed the two things that made me switch to COSMIC, and I didn't expect to go back

Published Aug 11, 2026, 8:00 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. It wasn't an accident that COSMIC has a reputation for being a great desktop environment on Linux, and it earned a spot on my machine awhile back for its great hardware support. For a decent stretch, it felt like it was better at handling multiple high refresh rate displays than other environments, but while using it, my heart longed for the environment where I had originally come from. GNOME, for better and for worse, has always been my go-to desktop on Linux. It, too, has quite a reputation, but it's not nearly as positive. Despite that, a couple of the features that I left GNOME for recently become defaults with GNOME 50, and now that they're finally out of the experimental phase, I've happily switched back. Variable refresh-rates are officially a default It's been available before, but it's now in a GUI GNOME shipped variable refresh rate as an experimental feature back in version 46, and while it did work, it required you to add a string to the mutter experimental-features key and relogin. Unless you were reading patch notes around this time, you definitely missed it. COSMIC, by contrast, exposed the setting from its fourth alpha, even featuring a choice between turning it on permanently or having it only engage with fullscreen apps. GNOME 50 finally removed that experimental label and put the feature in the normal display settings, and on distros that haven't already enabled them downstream, it's on by default. One of the noteable new functionalities is the low-latency cursor, which seems like a small addition, but it feels worlds better than the experimental version implementation. While VRR is active, the pointer now updates independently of application frame rate, so it keeps tracking at your display's maximum refresh even when a game is running well below it. If you have ever moved your mouse during a 45 FPS section on a 240 Hz panel and watched the cursor turn to molasses, that is the problem it solves, and COSMIC has no equivalent that I am aware of. I will still hand COSMIC the design win. Automatic-on-fullscreen is the correct default for a desktop that also plays games, and GNOME's per-monitor on-off toggle is a bit ham-fisted, but I'll take it over no VRR at all. Fractional scaling became a real setting One of the biggest complaints about GNOME is finally gone GNOME could always do 125 and 150 percent scaling, but the problem was that doing so meant enabling scale-monitor-framebuffer by hand, and that made anything running through XWayland a soft, blurry mess. GNOME 50 makes it a default, selectable in the settings and it's unnoticeable, which is how scaling should act. What it does not do is finish the XWayland half. Native XWayland scaling is exposed as a separate option, at least on Ubuntu, with an explicit warning that some legacy applications will end up oversized or blurry with it enabled, and the warning is correct. There are open mutter issues covering fullscreen XWayland clients rendering blurry at fractional scales even when the application is set to the monitor's native resolution, and a separate one where XWayland windows come out dramatically undersized with native scaling on. If your daily workflow leans on Electron applications, Wine, or Steam, this is the part to test before you commit. To be clear, COSMIC isn't in the clear with fractional scaling either, as it was just patching up fractional scaling pointer accuracy in some of its most recent releases. HDR is the one gap that hasn't closed GNOME has COSMIC beat here, and it was the straw that broke the penguin's back for me GNOME has had per-monitor HDR toggle for a couple versions to this point, and GNOME 50 built on it with support for the new Wayland color management protocol, which is an SDR-native color mode aimed at support for wide-gamut displays and HDR screen sharing—two things that apply to me directly. I record with software often with HDR enabled, and previously on Linux, I had to make concessions in this regard. COSMIC has none of this. HDR and Night Light are Epoch 3 items on System76's published roadmap, with the Vulkan renderer planned for Epoch 2 partly as the groundwork that makes HDR possible. System76 describes an Epoch as roughly six to eight months of development, and COSMIC is still in Epoch 1. With all of that said, though, GNOME's HDR is still unfinished. The one big missing piece here is HDR gaming, and while COSMIC still doesn't have true HDR support on the desktop, GNOME is unfortunately missing this crucial piece of the equation. Gamescope HDR renders washed out under GNOME because GNOME lacks scRGB and frog-color-management-v1 support, which is an unfortunate gap given how much Linux HDR gaming routes through gamescope. COSMIC is an excellent environment, but GNOME feels like home to me Maybe it's a little bit of Stockholm Syndrome, but I feel like all roads eventually lead back to GNOME for me. KDE feels too much like Windows-lite for me, and COSMIC just doesn't have the feature parity right now. Stock GNOME leaves a lot of gaps, but with the help of some tweaks and extensions, it feels the most intuitive to me out of the big Linux desktop environments, and that, along with these features, is why I returned to GNOME.