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