Hi Marius, On 7 March 2018 at 17:36, Marius Vlad <marius-cristian.v...@nxp.com> wrote: > Otherwise when setting dpms level DPMS_ON, weston_output_schedule_repaint() > will bail out early and never get a chance to wake up the output. > > Arguably this could also be done in drm_set_dpms() when setting > dpms_off_pending > but I figure it better to do it when deferred.
Thanks, that's a good catch, but I do wonder how it wasn't getting tripped up before. In previous releases, we'd call drm_set_dpms() from anywhere, which would block on the update completing and then set the DPMS level. I wonder if it's because we would receive a flip-done event anyway and call weston_output_finish_frame() after the DPMS had completed, which would drive us into repaint-idle. I suspect we should be calling finish_frame() to match that behaviour, to indicate that the previous update has completed, and then synchronously applying DPMS state. Pretending that disable/destroy/DPMS-off can be called at any time is really biting though. :( Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
