Re: [PATCH weston 1/1] compositor: Abort on bad page flip timestamps

[Pekka Paalanen <ppaalanen@gmail.com>]

On Thu, 06 Nov 2014 16:08:56 +0900
Michel Dänzer <michel@daenzer.net> wrote:

> On 06.11.2014 03:06, Frederic Plourde wrote:
> > Many features, like animations, hardly depend on page flip timestamps
> > to work properly, but some DRM drivers do not correctly support page flip
> > timestamps (or not at all) and in that case, things start to go wrong.
> >
> > This patch adds sanity check to weston_output_finish_frame. By solely
> > verifying that page flip timestamps are monotonically increasing, we
> > make sure that :
> >
> > 1) Underlying driver is not throwing zeroed-out timestamp series at us.
> > 2) We have not mistakenly jumped backwards because of integer overflow.
> >
> > If a pathological case is detected, we gracefully exit Weston
> > with an appropriate exit code to help developers debug their drivers.
> 
> That seems a bit harsh. IIRC, zero can be returned for the timestamp 
> intermittently if no accurate timestamp value can be determined, e.g. 
> because the CRTC is disabled. At the very least, I'd recommend 
> double-checking this with Mario Kleiner (Cc'd) and the dri-devel mailing 
> list.

Can that really happen if we are not doing stupid things like
attempting to flip on a disabled crtc or output?

Or can it happen, if we schedule a flip, then disable the crtc
before the flip completes? Or maybe when an output is hot-unplugged?

Is zero a special timestamp that simply cannot be produced during
normal operations, like due to clock wrap-around?


Thanks,
pq
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel