https://bugs.freedesktop.org/show_bug.cgi?id=79502
Frederic Plourde <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #2 from Frederic Plourde <[email protected]> --- This patch : http://cgit.freedesktop.org/~fredinfinite23/weston/commit/?h=bad_timestamp_abort&id=507cfb65fba6ed2f4e0b3973f6335ba98aa97894 is a fix for this, but I'd like to discuss it some more, because I feel there is something missing: 1) False-positive detection: What if DRM driver 'sanely' returns a timestamp = 0 either by (mis)chance or because of some weird DRM initial condition/behavior (first frame ?). We should be given another chance to repaint. 2) Integer overflows: What if we arrived at frame_time's max_range ? Next timestamp would then break the 'cur > prev' rule and we would wrongly abort Weston. I think those two considerations above call for some 'counter' on the detection. Chances that we 'sanely' hit (stamp==0 || cur < prev) are really low, but chances that we hit that twice in a row are practically 0. I don't see any need for a customizable counter; I would set it to 1 by default and exit Weston when it's 0. opinions on that please :) -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ wayland-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-bugs
