[PATCH weston] libweston/compositor-drm: Reset repaint scheduled status when setting DPMS level to off

[Marius-cristian Vlad]

On Fri, 2018-03-23 at 21:30 +0300, Greg V wrote:
> > On 7 March 2018 at 17:36, Marius Vlad <marius-cristian.vlad at
> > nxp.com 
> > <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fwayland-
> > devel&data=02%7C01%7Cmarius-
> > cristian.vlad%40nxp.com%7Cf1acbc5280754c8936a908d590ec293a%7C686ea1
> > d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636574266340740999&sdata=Q60NW
> > AAtygRpT0s55ToG%2Fkz5DloXqOM5Bhy5xIEO6PM%3D&reserved=0>> 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?
Hi,

When the monitor wakes up it will eventually start drawing. From your
description seems to be a different issue. This (patch) relates to
Daniels' basic atomic modesetting patches that have landed in a few
weeks ago, and to me it seems you are (still) using the legacy KMS page
flip ioctl.


> 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|

Yes, failing to queue page flips will lead a frozen image on the
screen. 

>