From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "Kristian Høgsberg" <krh@bitplanet.net>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: VT switchless v3
Date: Tue, 19 Feb 2013 10:15:09 -0800 [thread overview]
Message-ID: <20130219101509.720585c6@jbarnes-desktop> (raw)
In-Reply-To: <CAOeoa-cBFmUTNLifr8b-uVqfqJ0c=P=g=ywN=ggtW37xsqXTRQ@mail.gmail.com>
On Mon, 18 Feb 2013 19:58:26 -0500
Kristian Høgsberg <krh@bitplanet.net> wrote:
> On Mon, Feb 18, 2013 at 10:03 AM, Daniel Vetter <daniel@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2013-02-19 18:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-15 21:23 VT switchless v3 Jesse Barnes
2013-02-15 21:23 ` [PATCH 1/6] drm/i915: don't restore LVDS enable state blindly v2 Jesse Barnes
2013-02-15 21:23 ` [PATCH 2/6] drm/i915: add sprite restore function v2 Jesse Barnes
2013-02-18 17:19 ` Ville Syrjälä
2013-02-19 18:16 ` Jesse Barnes
2013-02-15 21:23 ` [PATCH 3/6] drm/i915: restore cursor and sprite state when forcing a config restore Jesse Barnes
2013-02-15 21:23 ` [PATCH 4/6] drm/i915: enable VT switchless resume v2 Jesse Barnes
2013-02-15 21:23 ` [PATCH 5/6] drm/i915: emit a hotplug event on resume Jesse Barnes
2013-02-15 21:23 ` [PATCH 6/6] drm/i915: remove disabled memset of framebuffer from intel_fb Jesse Barnes
2013-02-18 15:03 ` VT switchless v3 Daniel Vetter
2013-02-19 0:58 ` Kristian Høgsberg
2013-02-19 18:15 ` Jesse Barnes [this message]
2013-02-19 18:13 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130219101509.720585c6@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=krh@bitplanet.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).