Mutter, wir danken dir!
Wow. I was not expecting this especially considering that feature freeze was in place for gnome 46.
this warrants a new monitor for me, been holding out over a year with my old display, waiting for something and now I know what that was
Looking forward to giving VRR a shot again. Last time I tried a couple years ago was pretty underwhelming on a couple different machines. Some games worked well with it, but a lot of software felt subtly broken. A lot of weird micro-stuttering and stuff just not feeling smooth even when the average framerate was high compared to boring synced 144 hz.
It’s something I would actually refer to as “magical” in terms of what it does for input latency and frame tearing.
It’s the primary reason I have KDE on my gaming rig.
Can’t wait to try it!
Ya got some quite not rounded numbers there …
In video, common frame rates are 30, 29.97, 24, and 23.976. (Almost) anything else will be a multiple of those. Your monitor might not actually run at 30hz * 4, it runs at 29.97hz * 4 which is why you see an option like 119.88. Sometimes that’s displayed as 120 to the user for simplicity, but in this case they’re showing the actual value (or it might support both).
Where do the weird fractions come from?
Windows hides the actual refresh rate to make it look better. Linux shows you what it actually is.
I think it’s because of HDMI the values aren’t whole.
DisplayPort would display whole numbers
I don’t think that’s it, rather the monitors supported refresh rates. (Think!=know)
Wait, so if I get a 144hz monitor, only now will that work in say, standard Fedora or Ubuntu?
@FrankTheHealer @KarnaSubarna Setting displays to run at 144Hz has worked for ages. VRR is a different feature, where the display’s refresh rate syncs to the framerate being pushed to it by your OS. Most environments have supported that for ages too, but some things haven’t. Mutter moving to support it is a big step toward it being universally available.
Ah that makes sense. Thank you for the info
