[PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC

[Michel Dänzer]

On 2018-10-15 11:47 a.m., Christian König wrote:
> 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.

Certainly not DRI2, but for now we're not enabling VRR with that anyway.

While the X11 Present extension specifies PresentOptionUST for this,
support for it isn't implemented yet in xserver (as in setting the
option has no effect, the X server interprets the target value as an MSC
anyway).

So this couldn't work before the next major release of xserver, which
based on recent history could be at least about one year away.

In contrast, the CRTC property based solution for the gaming use-case
can work even with older xserver versions.


> 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.

Apart from the above, another issue is that this would give direct
control to the client on whether or not VRR should be used. But we want
to allow the user to disable VRR even if a client wants to use it, via
an RandR output property. This requires that the Xorg driver can control
whether or not VRR can actually be used, via the CRTC property added by
this patch.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer