On Mon, 18 Feb 2013 19:58:26 -0500 Kristian H?gsberg <krh at bitplanet.net> wrote: > On Mon, Feb 18, 2013 at 10:03 AM, Daniel Vetter <daniel at ffwll.ch> wrote: > > On Fri, Feb 15, 2013 at 01:23:08PM -0800, Jesse Barnes wrote: > >> A few more fixes from Daniel. > > > > So one thing that crossed my mind which we should at least quickly > > discuss: How is userspace supposed to notice the resume? On a lot of > > desktops (and even Androids) the normal thing seems to be to draw the > > screensave/lock after resume, which means that we'll show the desktop for > > a frame or so. Which is not too nice. Is userspace simply supposed to draw > > the screen lock before sleep, or does it need a helping hand from the > > kernel to fix this issue? > > Yup, I second that and I've mentioned it to Jesse before. VTs in > KD_GRAPHICS mode are already responsible for re-setting their mode > when you switch back to them after having switched away. Surely they > should have the option to handle setting mode and potentially present > a lockscreen when coming back from resume. In case of weston, we have > the option to handle this very well, since the compositor can launch > prepare a lock screen (potentailly launching a helper client to do > that) and just not set a mode or dpms on until the UI is ready. Rob Bradford mentioned that GNOME had a bug here where on suspend the lock screen daemon would be notified, but the suspend would happen too quickly for it to actually receive the notification and take action. So when you resumed, you'd see your desktop until the daemon was re-run and then the lock screen would appear. That's been fixed apparently, but it illustrates that you don't want to do things on resume, you want to do them on suspend like Kristian points out. -- Jesse Barnes, Intel Open Source Technology Center
