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/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel