On 7 March 2018 at 17:36, Marius Vlad <marius-cristian.vlad at nxp.com
<https://lists.freedesktop.org/mailman/listinfo/wayland-devel>> 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.
Hi! I think I might have tripped that up before.
Or a different DPMS bug?
Does "wake up the output" here mean DPMS wake, or starting drawing to that
output again?
One of my monitors, which is quite slow to wake up (AOC U2879VF) pretty often
becomes frozen after waking up from DPMS.
While on the other monitor (an old NEC MultiSync) this problem never happened.
So like I could move the mouse and see the picture change on that monitor, but
the first one was still displaying the frozen picture from before going to
sleep.
The log lines were:
|[00:42:10.740] queueing pageflip failed: m [00:42:10.740] Couldn't apply
state for output DP-2|
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
