Bug 73842

Summary: Haswell: lock screen disappears temporarily after dmps force off/on (laptop lid close/open)
Product: DRI Reporter: uriahheep <uriahheep>
Component: DRM/IntelAssignee: Antti Koskipaa <antti.koskipaa>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
dmesg
none
strace of i3lock including when i close/open lid
none
Xorg.0.log with --enable-debug=full (segmentation fault)
none
Xorg.0.log from git master with --enable-debug=full none

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

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]
dmesg
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?

Thanks,
uriah
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.

Cheers,
uriah
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,
                                            sna->scrn->virtualX,
                                            sna->scrn->virtualY,
@@ -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->virtualX,
                                    sna->scrn->virtualY)) {
Comment 10 uriahheep 2014-01-21 18:33:11 UTC
It works!

Cheers!
uriah

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.