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.
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.
Great. I heard there were flickering issues under some niche scenarios, due to the cursor and the content being displayed becoming out of sync with one another, that were 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 though.
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!
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.
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?
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.
Only on Debian Stable
