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