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