Bug 73842 - Haswell: lock screen disappears temporarily after dmps force off/on (laptop lid close/open)
Summary: Haswell: lock screen disappears temporarily after dmps force off/on (laptop l...
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Antti Koskipaa
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2014-01-20 19:09 UTC by uriahheep
Modified: 2017-07-24 22:56 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Xorg.0.log (17.10 KB, text/plain)
2014-01-20 19:09 UTC, uriahheep
no flags Details
dmesg (87.01 KB, text/plain)
2014-01-20 19:11 UTC, uriahheep
no flags Details
strace of i3lock including when i close/open lid (78.38 KB, text/plain)
2014-01-20 19:17 UTC, uriahheep
no flags Details
Xorg.0.log with --enable-debug=full (segmentation fault) (1.81 MB, text/plain)
2014-01-20 22:24 UTC, uriahheep
no flags Details
Xorg.0.log from git master with --enable-debug=full (2.78 MB, text/plain)
2014-01-20 23:18 UTC, uriahheep
no flags Details

Description uriahheep 2014-01-20 19:09:23 UTC
Created attachment 92478 [details]

On a MacBook Pro 11,1 (late 2013 13", Intel Haswell / Iris 5100), when acpid detects lid close/open it'll call xset -display :0 dpms force off or on (because for some reason the screen doesn't turn off by itself when the lid closes). Meanwhile, before I close the lid, I manually run i3lock, but when I open the lid up again the desktop is visible for a fraction of a second, and then i3lock's blank screen reappears. This does not happen on another of my machines with a Pineview Intel chip (GMA 3150 I believe). I understand that this may not be a graphics driver bug at all, however since it only happens on this Haswell chip it very well might be.
Comment 1 uriahheep 2014-01-20 19:11:40 UTC
Created attachment 92479 [details]
Comment 2 uriahheep 2014-01-20 19:17:24 UTC
Created attachment 92480 [details]
strace of i3lock including when i close/open lid
Comment 3 Chris Wilson 2014-01-20 20:39:37 UTC
Try not enabling TearFree.
Comment 4 uriahheep 2014-01-20 21:00:54 UTC
You're spot on. Disabling TearFree solved the issue.

Furthermore, testing i3lock using the fbdev xorg driver with the nomodeset kernel commandline option also did not reproduce the issue.

Do you have any idea what in the TearFree code might be causing this?

Comment 5 Chris Wilson 2014-01-20 21:08:49 UTC
Nope. Give me a Xorg.0.log with --enable-debug=full and I might be able to piece together where the i3lock buffer went.
Comment 6 uriahheep 2014-01-20 22:24:09 UTC
Created attachment 92492 [details]
Xorg.0.log with --enable-debug=full (segmentation fault)

Ok, here you go. I'm not sure whether it segfaults when the lid closes or opens... When I opened the lid it showed the VT and then went to a black screen that I couldn't get out of.

Comment 7 uriahheep 2014-01-20 23:18:41 UTC
Created attachment 92494 [details]
Xorg.0.log from git master with --enable-debug=full
Comment 8 Chris Wilson 2014-01-21 10:03:04 UTC
Ah, when waking up from DPMS off we bind a dirty framebuffer. That lasts for a whole 1s before the screen is finally refreshed with the correct content. Does that match your experience?
Comment 9 Chris Wilson 2014-01-21 10:16:44 UTC
My theory is that this should be fixed by:

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 000d9ab..5ab42ec 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -1422,6 +1422,8 @@ static struct kgem_bo *sna_crtc_attach(xf86CrtcPtr crtc)
                DBG(("%s: attaching to single shadow pixmap\n", __FUNCTION__));
                if (sna->mode.shadow == NULL) {
+                       BoxRec box;
                        bo = kgem_create_2d(&sna->kgem,
@@ -1431,6 +1433,18 @@ static struct kgem_bo *sna_crtc_attach(xf86CrtcPtr crtc)
                        if (bo == NULL)
                                return NULL;
+                       box.x1 = box.y1 = 0;
+                       box.x2 = sna->scrn->virtualX;
+                       box.y2 = sna->scrn->virtualY;
+                       if (!sna->render.copy_boxes(sna, GXcopy,
+                                                   sna->front, sna_pixmap(sna->front)->gpu_bo, 0, 0,
+                                                   sna->front, bo, 0, 0,
+                                                   &box, 1, 0)) {
+                               kgem_bo_destroy(&sna->kgem, bo);
+                               return NULL;
+                       }
                        if (!get_fb(sna, bo,
                                    sna->scrn->virtualY)) {
Comment 10 uriahheep 2014-01-21 18:33:11 UTC
It works!


p.s. where should I file a report about the screen not automatically shutting off when lid is closed? That's supposed to happen, right?
Comment 11 Chris Wilson 2014-01-21 21:41:35 UTC
(In reply to comment #10)
> p.s. where should I file a report about the screen not automatically
> shutting off when lid is closed? That's supposed to happen, right?

Hmm, yes. Kernel detects lid event, sends hotplug notification, userspace wakes up sees the lid is closed and/or the panel is disconnected and turns off the panel. (Any one of those steps may be at fault - you can at least watch what userspace does by tracing X, it serves as the hub for events and commands). Sometimes this is complicated by the firmware interceding and turning things off on its own accord.
Comment 12 Chris Wilson 2014-01-21 21:42:00 UTC
commit 2c441079cbd52902d356b652659e2be84726940e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 21 10:17:03 2014 +0000

    sna: Initialise the TearFree shadow output from the current front buffer
    Otherwise we may end up in a sitation where we show stale contents for a
    (sometimes signification) fraction of a second before it is refreshed
    with the correct contents.
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73842
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.