- cross-posted to:
- linux_gaming@lemmit.online
- cross-posted to:
- linux_gaming@lemmit.online
As pointed out in This Week in GNOME, there’s been some continued work on Variable Rate Refresh for the GNOME desktop. The VRR setting within GNOME Settings continues to be iterated on as the developers iron out how they’d like to present the Variable Rate Refresh setting for users. The developers have been discussing how to best present the option as to avoid confusion as well as how it makes the most technical sense as far as the option goes.
Edit: “Variable Refresh Rate - Roadmap” - https://gitlab.gnome.org/GNOME/mutter/-/issues/3125
You must log in or register to comment.
The Steam Deck is what got me to finally try modern KDE and eventually switch to it. I recently moved my gaming PC to Fedora 39, and considered trying Gnome again for variety’s sake until I remembered that it currently does not natively support VRR, so this is good news.
I think I prefer Plasma at this point, and I’m excited with Plasma 6 around the corner, but my desktop PC is basically a gaming appliance, so I think the relative simplicity of Gnome might be nice to run on there eventually as these features catch up. I like to have variety in what I’m running anyways. I appreciate that it gives me a wider perspective on my preferences.
The lack of VRR in GNOME is what had me change to KDE. I prefer GNOME in many ways, but I was tired of having to use the vrr patches to keep the functionality.
This. As soon as GNOME gets VRR & HDR, I think I’m going back. Also, I’ve read Steam has great integration with KDE, does anyone know how exactly?
I don’t think in any way that would lose an advantage over gnome.
Having a Steam Deck, the only integration I see is the “Return to Steam” shortcut and a change to the logo.
When you run the Steam Deck gaming mode it bypasses KDE entirely and uses its own game scope compositor.
I thought its an entire different desktop. Especially itd not possible to run gamescope while a X11 Desktop is running so I guess you are wrong with “bypassing”. Its just switching to gamescope. Its a Wayland compositor. It does even less than a Window Manager (is this right?)
Bypass is maybe a poor choice of words. Both gamescope and Kwin are compositors so you can use one or the other.
An advantage of making gamescope is that they can add features like VRR or HDR without having to wayiting for KWin to implement it
I assume as this is a Gaming mode, its purpose is not to avoid waiting for features. But close the entire desktop which may use up to 1GB RAM and a by of CPU. Which definetly impacts the game by some fraction. Doesnt matter how tiny, its just what gaming modes are having as focus I assume.
The next thing I would never see on a desktop is FSR which gamescope has.
I run GameScope for CS2. The rest of the desktop runs Wayland.
Yeah, this setting is possible as your underlying desktop uses Wayland
Yup. Gamescope doesn’t work without Wayland.
According to GloriousEggroll it goes way beyond that. I just don’t know what it does.
If you are using Arch, it can be enabled (though it’s still experimental) [1]
[1] https://wiki.archlinux.org/title/Variable_refresh_rate#GNOME
Have you tried it? How is stability?
My monitor is old, doesn’t support VRR 😕
I used it previously. I never had crashes because of it, but it would mean I would have to wait for the aur packages to be updated before I could upgrade to the next iteration of GNOME.
This is what Windows should be focusing on rather than trying to shove AI crap everywhere.
Agreed. Windows’ HDR support is rough. It’s fine for gaming, but you can’t display SDR and HDR content together like MacOS. I think that’s why Apple holds a big part of the market for creatives.
I wish GNOME had DRM on Wayland, kinda annoying to always have to switch to Xorg for VR
Great. I heard there was a cursor flickering issue under some niche scenarios, due to the cursor and the content’s framerates becoming out of sync with one another after exiting some full screen apps, that was previously preventing the merge of this feature.
I’m assuming it’s been solved?
The “Preserve battery healthy by keeping charge between 20% and 80%” is a nice option too
I find GNOME’s “must be perfect” approach to accepting new code counterintuitive.
One of the largest benefits of having a clean architecture is increased velocity and extensibility. What’s the point in nitpicking over perfection when it takes literally years to merge a feature, arguably one considered basic and essential by today’s standards?
KDE is on the other side of this pendulum, integrating everything and resulting in a disjointed, buggy disaster.
Where’s the middle way? It used to be XFCE. What is it now?
I definitely get what you mean, and sometimes agree, but tbh I’m glad Gnome is an option for those who want a DE that is uncompromisingly UX-focused and straight up won’t accept changes until they’re damn sure it’ll be production-ready.
And while they’ve been relatively slow in getting adaptive refresh working, they’ve been very quick with some other things. Idk why it took them this long to sort out the cursor occasionally becoming out of sync with displayed content’s refresh rate, but there must be a reason for it.
Gnome was at the forefront with Wayland, PulseAudio, they’ve been the biggest pusher of Portals, pretty much all of their GTK4 apps have been designed to also be compatible with mobile devices. Accessibility features on Gnome are also pretty great for a Linux DE.
As a general rule, I’d say their development process works well, despite there being the occasional holdup.
And while Plasma obviously isn’t nearly as bug-free as Gnome, it’s come a long way since the Plasma 4/early Plasma 5 days. I still don’t feel I can depend on it the same as I could for Gnome or Cinnamon (compositor crashes bringing down all open apps is a big issue in particular - and is finally due to be fixed in Plasma 6), but don’t underestimate their progress — since like 5.15/5.16 they’ve improved leaps and bounds.
And with 6 it looks like they’ve learned from the mistakes of 4 and 5’s launches.
Quality control is important for a project that is going to be supported for long time, and used by many. Slow but steady is a right approach for open source project, IMO.
KDE is very stable.
Lol
Only on Debian Stable
Wonder if COSMIC will launch with VRR
It already supports VRR and DRM leasing. VRR monitors and VR headsets have been tested.
I’m currently daily driving Ubuntu 22.04 LTS. I didn’t think GNOME would be all my thing, but it’s really intuitive and has just enough options to satisfy all my desires (okay, I needed the gesture improvements extension for some of them).
It’s great to see GNOME focusing on what really matters. I think because they keep it simple to the user, they have more time to focus on important but harder to implement features rather than focusing on heavy customization (I love KDE too, don’t worry) But now I want to switch to Fedora or something bleeding edge, because of GNOME.
Why is that a
GnomeWM thing and not a X/Wayland thing?I think the compositor, Mutter in Gnome’s case, has to explicitly request VRR from the display driver via the Wayland protocol. So it’s a bit of each.
via the Wayland protocol
There’s no Wayland protocol involved, Mutter directly talks to the kernel
Ah, I see, thank you for the correction. Does Wayland only encompass communication between clients and the server? I’ve seen some code calling the wlroots functions for requesting VRR and some of how the Nvidia open kernel modules respond. Is requesting VRR a part of Kernel Mode Setting, then?
Does Wayland only encompass communication between clients and the server?
Yes
Is requesting VRR a part of Kernel Mode Setting, then?
Also yes
Thanks!
I believe it’s actually a Mutter thing [1]
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154
It is an X thing. Wayland is a protocol not a display server though, so for Wayland the Wayland compositor has to implement it (Mutter in this case)
Right, yeah. The thing i don’t like about Wayland; duplication of code/work for every WM.
This is the best summary I could come up with:
There’s been some new work pending for further enhancing the GNOME desktop when it comes around Variable Rate Refresh (VRR).
Separately, there’s new merge requests pending for adding laptop battery charge threshold controls from the GNOME UI.
GNOME has also seen some fixes around removing certain assumptions around fixed refresh rates and cursor movement becoming synchronized with the main content updates after performing a VT switch.
Some other interesting but separate work being carried out is by GNOME developer Jelle van der Waa for offering up battery charge controls.
This is to make use of the exposed Linux kernel charge control start/end thresholds for helping to preserve battery health for laptops frequently plugged in 24/7.
There are merge requests pending for UPower as well as the GNOME Control Center for allowing users to easily toggle this option to preserve the battery health for frequently plugged in systems by keeping the charge level in the 50~80% range.
The original article contains 259 words, the summary contains 156 words. Saved 40%. I’m a bot and I’m open source!
