Am 15.10.2018 um 11:40 schrieb Michel Dänzer:
On 2018-10-13 7:38 p.m., Christian König wrote:
Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas:
This patch introduces the 'vrr_enabled' CRTC property to allow
dynamic control over variable refresh rate support for a CRTC.
This property should be treated like a content hint to the driver -
if the hardware or driver is not capable of driving variable refresh
timings then this is not considered an error.
Capability for variable refresh rate support should be determined
by querying the vrr_capable drm connector property.
It is worth noting that while the property is intended for atomic use
it isn't filtered from legacy userspace queries. This allows for Xorg
userspace drivers to implement support.
I'm honestly still not convinced that a per CRTC property is actually
the right approach.
What we should rather do instead is to implement a target timestamp for
the page flip.
You'd have to be more specific about how the latter could completely
replace the former. I don't see how it could.
Each flip request send by an application gets a timestamp when the flip
should be displayed.
If I'm not completely mistaken we already have something like that in
both DRI2 as well as DRI3.
So as far as I can see we only need to add an extra flag that those
information are trust worth in the context of VRR as well.
If we don't set this flag we always get the always working fallback
behavior, e.g. VRR is disabled and we have a fixed refresh rate.
If we set this flag and the timestamp is in the past we get the VRR
behavior to display the next frame as soon as possible.
If we set this flag and specific a specific timestamp then we get the
VRR behavior to display the frame as close as possible to the specified
timestamp.
Regards,
Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
