[PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

[Kazlauskas, Nicholas]

On 10/05/2018 12:56 PM, Michel Dänzer wrote:
> On 2018-10-05 6:21 p.m., Kazlauskas, Nicholas wrote:
>> On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
>>>
>>> 2. User preference
>>>      A toggle on the desktop environment's display settings
>>>      application to allow or disallow VRR. After all, video mode
>>>      configuration is here too, and ideally applications should not
>>>      mess with the video mode directly.
>>
>> [...]
>>
>> User preference can be handled as part of the DDX driver with something
>> like an X Option. Dropping the variable_refresh_enabled property in
>> favor of this works. This covers 2.
> 
> The Xorg driver can expose a RandR output property, even if the kernel
> doesn't expose a corresponding connector property. See e.g. the TearFree
> output property in xf86-video-amdgpu.

The new configuration property for the DDX side of things does pretty 
much that.

> 
> 
>>> I also believe that it would be useful to expose vmin/vmax to userspace
>>> as properties, so that display servers and apps can plan ahead on when
>>> they will render. I suppose that can be left for later when someone
>>> starts working on userspace taking advantage of it, so that the proper
>>> userspace requirement for new UABI is fulfilled.
>>
>> Knowing the vmin/vmax could potentially be useful for testing but most
>> applications shouldn't be trying to predict or adjust rendering based on
>> these.
> 
> FWIW, recent research indicates that this is necessary for perfectly
> smooth animation without micro-stuttering, even with VRR.
> 
> 

This was brought up in previous RFCs about this but I'm not really 
convinced by the research methodology and the results from those threads.

Targeting the max vrefresh of the display (which is known without 
additional properties) should be best for prediction since anything 
lower would be inherently less smooth by definition.

Nicholas Kazlauskas