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

From: "Christian König" <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
	christian.koenig-5C7GfCeVMHo@public.gmane.org,
	"Nicholas Kazlauskas"
	<nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
Cc: daniel.vetter-/w4YWyX8dFk@public.gmane.org,
	Marek.Olsak-5C7GfCeVMHo@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Alexander.Deucher-5C7GfCeVMHo@public.gmane.org
Subject: Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC
Date: Mon, 15 Oct 2018 11:47:12 +0200	[thread overview]
Message-ID: <c9afd2f9-c80c-3147-6458-14e386196fb7@gmail.com> (raw)
In-Reply-To: <9811fdab-3efe-4701-92e1-0f53b323959d-otUistvHUpPR7s880joybQ@public.gmane.org>

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx