[PATCH v4 3/4] drm: Document variable refresh properties

[Ville Syrjälä]

On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
> > On Fri, Oct 26, 2018 at 05:34:15PM +0000, Kazlauskas, Nicholas wrote:
> >> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> >>>
> >>> Speaking of timestamps. What is the expected behaviour of vblank
> >>> timestamps when vrr is enabled?
> >>
> >> When vrr is enabled the duration of the vertical front porch will be
> >> extended until flip or timeout occurs. The vblank timestamp will vary
> >> based on duration of the vertical front porch. The min/max duration for
> >> the front porch can be specified by the driver via the min/max range.
> >>
> >> No changes to vblank timestamping handling should be necessary to
> >> accommodate variable refresh rate.
> > 
> > The problem is that the timestamp is supposed to correspond to the first
> > active pixel. And since we don't know how long the front porch will be
> > we can't realistically report the true value. So I guess just assuming
> > min front porch length is as good as anything else?
> 
> That (and documenting that the timestamp corresponds to the earliest
> possible first active pixel, not necessarily the actual one, with VRR)
> might be good enough for the actual vblank event timestamps.
> 
> 
> However, I'm not so sure about the timestamps of page flip completion
> events. Those could be very misleading if the flip completes towards the
> timeout, which could result in bad behaviour of applications which use
> them for animation timing.
> 
> Maybe the timestamp could be updated appropriately (yes, I'm hand-waving
> :) in drm_crtc_send_vblank_event?

Hmm. Updated how? Whether it's a page flip event or vblank even we won't
know when the first active pixel will come. Although I suppose if
there is some kind of vrr slew rate limit we could at least account
for that to report a more correct "this is the earliest you migth be
able to see your frame" timestamp.

Oh, or are you actually saying that shceduling a new flip before the
timeout is actually going to latch that flip immediately? I figured
that the flip would get latched on the next start of vblank regardless,
and the act of scheduling a flip will just kick the hardware to start
scanning the previously latched frame earlier.

scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank
                  ^                ^        ^               ^
                  |                |        flip C          latch C
                  flip B           latch B

vs.

scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank
                  ^ ^                      ^ ^
                  | latch B                | latch C
                  flip B                   flip C

The latter would seem more like a tearing flip without the tearing.

-- 
Ville Syrjälä
Intel