• Adjusting the refresh rate to the performance of the desktop is one.

          That’s the definition, isn’t it? Why is this better than a fixed refresh rate? Can the monitor scale the rate down to consume less power or something?

          I also heard it would make it easier to manage multiple monitors sporting different refresh rates, although I haven’t had issues with that personally.

          I heard that too and got similarly confused. I work with two monitors with different refresh rates (75 and 60) on Mint and it seems fine. Is X downgrading my 75 Hz monitor to 60 silently? I don’t know how to check that.

            1. To avoid having to skip frames to make the desktop look more fluid, thus matching the refresh rate of the monitor.

            2. I think the whole desktop runs at the higher refresh rate when you have mismatched monitors? Not sure. Wayland and X11 might differ as well on how they handle this.

          • Can the monitor scale the rate down to consume less power or something?

            In theory, yes. However, I have never seen it used that way. The only widely used applications for VRR are games and video playback.

            Would be interesting to do some power measurements though.

            Is X downgrading my 75 Hz monitor to 60 silently?

            Yes, X does not support different refresh rates. Wayland does.

      • It’s mainly for games of course.

        It’s also good for video, as it can play videos at the highest possible Hz multiple of the video’s FPS. So for example 24 FPS video could be played back with 144 Hz, 25 FPS with 125 Hz etc. VRR isn’t technically required for this as many non-VRR monitors support different video modes with different fixed Hz as well, but the transition between Hz is seamless (no need to change video mode).

  • This is the best summary I could come up with:


    A merge request was opened this week for plumbing fractional scaling support for XWayland clients running on the GNOME Mutter compositor.

    Jonas Dreßler opened a merge request with a patch from Jonas Ådah that has been working on the functionality for allowing scaling-aware XWayland clients to scale themselves using the scale-monitor-framebuffers functionality.

    The patch explains: "When monitor framebuffers are scaled, this special cases Xwayland and sends output regions in a way that Xwayland think everything is N times as large as the logical region, where N is the ceil of the max monitor scale.

    Dreßler noted in the merge request that the coordinate space conversion has been working out well.

    Being past the feature freeze for GNOME 46, short of it being unexpectedly allowed as a late addition, it won’t be wrapped up until GNOME 47 in September.

    Similarly, also missing the feature freeze is the GNOME Variable Refresh Rate (VRR) functionality.


    The original article contains 237 words, the summary contains 152 words. Saved 36%. I’m a bot and I’m open source!