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

[Koenig, Christian]

Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
> On Wed, 10 Oct 2018 09:35:50 -0400
> "Kazlauskas, Nicholas" <nicholas.kazlauskas at amd.com> wrote:
>
>> The patches I've put out target this use case mostly because of the
>> benefit for a relatively simple interface. VRR can and has been used in
>> more ways that this, however.
>>
>> An example usecase that differs from this would actually be video
>> playback. The monitor's refresh rate likely doesn't align with the video
>> content rate. An API that exposes direct control over VRR (like the
>> range, refresh duration, presentation timestamp) could allow the
>> application to specify the content rate directly to deliver a smoother
>> playback experience. For example, if you had a 24fps video and the VRR
>> range was 40-60Hz you could target 48Hz via some API here.
> The way that has been discussed to be implemented is that DRM page flips
> would carry a target timestamp, which the driver will then meet as good
> as it can. It is better to define an absolute target timestamp than a
> frequency, because a timestamp can be used to synchronize with audio
> and more. Mario Kleiner can tell you all about scientific use cases
> that require accurate display timing, not just frequency.

To summarize what information should be provided by the driver stack to 
make applications happy:

1. The minimum time a frame can be displayed, in other words the maximum 
frame rate.
2. The maximum time a frame can be displayed, in other words the minimum 
frame rate.
3. How much change of frame timing is allowed between frames to avoid 
luminescence flickering.

Number 1 and 2 can also be used to signal the availability of VRR to 
applications, e.g. if they are identical we don't support VRR at all.

Regards,
Christian.

>
> A timestamp will naturally lend itself to arbitrary on-demand screen
> updates as well.
>
> However, userspace still needs to know if the target timestamp it is
> contemplating on could realistically be met, so that e.g. a video
> player can choose between showing video frames as is vs. needing to
> interpolate for the presentation times it actually can achieve.
>
> I suppose we agree on the above.
>
> Btw. would a video player even need explicit controls if it knows the
> display will adapt to the player's refresh rate? It could just use the
> original video rate and from what I understood, the display will soon
> end up refreshing at exactly that rate. The player can still use the
> realized page flip timestamps to synchronize with audio, since it can
> assume the refresh rate is stable and can predict the next few flips.
> But, this would only work if the video player knows that VRR will adapt
> to its rate.
>
> While we are talking about predictability of page flips, Weston is
> already relying on a prediction to reduce the desktop latency to
> screen. However, it should be possible to modify Weston to implement
> the kind of VRR support for fullscreen exclusive windows like you are
> proposing just fine.
>
> Just like the X11 window property you mentioned for marking windows as
> eligible for VRR in Xorg, Wayland will need a similar protocol
> extension.
>
> I'm happy to see work being done for VRR.
>
>
> Thanks,
> pq