Hi all,
I've been working on adding VRR support to Sway [1] (a Wayland compositor). The compositor just sets the VRR_ENABLED property.
This works fine for some screens, but causes flcikering for other screens as expected [2]. Fixing the flickering is something we've talked about last XDC [3]. The flickering is caused by physical limitations of the screen: changing the refresh rate too quickly results in brightness issues.
The approach taken by xf86-video-amdgpu is to only enable VRR if an app is fullscreen and not present in a special Mesa blacklist (e.g. Firefox is in the blacklist because it doesn't render at a fixed interval).
For Wayland, I'd prefer to avoid having a blacklist. I'd like to be able to use VRR in the general case (not just for fullscreen apps). A way to fix the flickering would be to implement a slew rate and make it so refresh rate variations are capped by the slew rate.
The main question is: should this be implemented in the kernel or in user-space?
I personally think it'd make more sense to implement this in the kernel. This would de-duplicate the slew rate logic between compositors and would avoid unnecessarily waking up user-space.
Moreover, it seems Intel hardware supports programming a slew rate directly. To take advantage of this feature the slew rate needs to be implemented in the kernel.
Harry, what do you think?
Thanks,
Simon
[1]: https://github.com/swaywm/sway/pull/5063 [2]: https://github.com/swaywm/sway/issues/5076 [3]: https://xdc2019.x.org/event/5/contributions/331/