Variable Refresh Rate & flickering screens

[Manasi Navare]

On Tue, Mar 17, 2020 at 09:25:33AM -0400, Harry Wentland wrote:
> 
> 
> On 2020-03-17 5:08 a.m., Simon Ser wrote:
> > On Thursday, March 12, 2020 3:43 PM, Harry Wentland <hwentlan at amd.com> wrote:
> > 
> >> Not the main VRR expert and we're still discussing this internally but I
> >> think it'll very much depend on the display whether you'll see flicker
> >> in this case.
> >>
> >> The other complication is that for gaming we don't want to use the
> >> cursor as a VRR trigger and only look at page flips in order to allow
> >> for smooth gameplay. For a desktop use-case that's probably not the
> >> right policy.
> > 
> > I think user-space can handle this and correctly synchronize cursor
> > updates with game updates via the KMS atomic API.
> > 
> > However I still think flickering should be avoided by the hardware.
> > Flickering is a completely separate issue and user-space shouldn't add
> > workarounds for screen issues like this.
> > 
> > Do you think that would be acceptable? Do you have any "slew rate
> > register" in AMD hardware?
> >

In case of Intel HW, we do have a way to program the maxshift so the max increment or
decrement in the vblank in successive frames. This is designed to be used for
the displays that  have a restriction on the maximum change in refresh rate between two consecutive frames.

But I am still figuring out how the panel indicates this restriction that we need to program
in the HW registers.

Harry/SImon, do you know of any such panels that have these restrictions and if they
indicate this limitation or the maxshift through EDID or DPCD?

Manasi
 
> 
> There are no slew rate registers in current AMD HW but I also think
> slewing would best be done in kernel space, either directly in HW by HW
> that supports it or in SW for HW that doesn't support it.
> 
> Harry
> 
> > Thanks,
> > 
> > Simon
> >