Skip to content
GitLab

backends/native: Add support for variable refresh rate

Open Dor Askayo requested to merge doraskayo/mutter:vrr-support into main

Status

The MR is now ready for review. There are a few small design decisions to make, but overall the core VRR experience is good enough in my tests.

There are some limitations still, and those are covered in the Caveats section.

TODO

  • Extensively test using VRRTest. (https://github.com/Nixola/VRRTest)
  • Test heavy OpenGL apps.
  • Test heavy Vulkan apps.
  • Test an "extend" multi-monitor configuration which combines VRR and non-VRR monitors.
  • Test a "mirror" multi-monitor configuration which combines VRR and non-VRR monitors.
  • Test clients that use subsurfaces.
  • Test clients that use the presentation-time protocol.

Background

This MR adds the logic required to detect monitors that are capable of VRR and the ability to activate it using KMS properties.

It also adds the ability to enable or disable VRR on capable monitors using the DisplayConfig DBus API, and makes this configuration persist via monitors.xml.

Finally, once configured to be enabled, VRR is actually activated on a monitor when a window that supports it covers the entire monitor on the visible workspace, doesn't have any transitions or animations, and isn't covered by any shell UI elements.

Caveats

Lower Refresh Rate with Non-throttled OpenGL Applications

Mutter doesn't wait for client frames to become ready for display before incorporating them into the next frame (#1162 (closed)), which means that its "frame presentation rate" (which is translated to monitor refresh rate in VRR) can be lower than the frame rate of its clients when they perform heavy rendering.

This issue doesn't affect Vulkan-based clients (at least when using Mesa drivers), since Vulkan drivers wait for rendered frames to be ready for display before sending them to Mutter.

To work around this issue, the rendering of such clients can be throttled to allow Mutter to display its frames on time. The easiest way to achieve this is by enabling VSync at the application level, or via the vblank_mode=3 environment variable.

Stutter in Cursor Movement with Passively Updating Fullscreen Clients

As a limitation of the atomic KMS API, it's not possible to update the cursor position more often than the display content. This means that when VRR is enabled and a client update rate is very low (such as a fullscreen Terminal window), the cursor position would similarly update less frequently.

As a partial workaround, this MR guarentees that the cursor update rate would be no less than 30 Hz. This limitation is set below most VRR refresh rate ranges to avoid negatively impacting the VRR effect due to cursor movement.

30 Hz is still a rather low update rate however, and can appear stuttery to some. A higher minimum update rate can be considered based on user feedback.

Missing Wayland Protocol

Support for VRR isn't advertised by Wayland (and Xwayland) clients at the moment since there is no Wayland protocol which allows it to be advertised. (wayland/wayland/issues/84) There are also alternative solutions being proposed. (https://lists.freedesktop.org/archives/dri-devel/2020-March/258940.html)

For now, it is assumed that every Wayland and X11 window supports VRR. This means that applications which have compatibility issues with VRR may behave poorly while it's active.

Notes

  • Temporary commits are used for testing purposes or work around issues that may need be solved in a different way. Each of them has its reasoning in its commit message.

Related MRs

Edited by Dor Askayo