On Fri, 2018-03-09 at 09:35 +0000, Daniel Stone wrote: > 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.
Indeed, I've submitted a previous patch because for timeline instrumentation because of this. weston_output_finish_frame() is being called with a NULL timestamp. > > 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. :( I don't know enough about the repaint machinery, should this be done from drm_set_dpms() or from drm_output_update_complete()?. I'm hitting some asserts in both cases, maybe I'm doing it wrong :/. > Cheers, > Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
