[PATCH weston 1/1] compositor: Abort on bad page flip timestamps
Pekka Paalanen
ppaalanen at gmail.com
Thu Nov 6 08:42:42 PST 2014
On Thu, 06 Nov 2014 16:08:56 +0900
Michel Dänzer <michel at 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
More information about the wayland-devel
mailing list