Bug 64675

Summary: xscreensaver won't go away with latest intel driver (regression)
Product: xorg Reporter: Nick Bowler <nbowler>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log none

Description Nick Bowler 2013-05-16 15:39:25 UTC 
After updating xf86-video-intel to latest git, xscreensaver appears to be broken.  The screensaver itself works, but the unlock dialog does not render at all (although the mouse pointer appears).  After entering my password, the (frozen) screensaver image remains on the screen where the unlock dialog should have been (obscuring everything on that display).  Switching VTs corrects the issue.  All of this is 100% reproducible.

The screen which did not try to display the xscreensaver password dialog works properly.

This issue occurs w/ SNA on a 2-screen Zaphod configuration with a G45 chip, running Xorg server 1.14.1.  It does not appear to happen on non-zaphod dual head configurations.

Bisection pinpoints the following commit:

16a64649e9c440ab9457467fe04be25719a73e7c is the first bad commit
commit 16a64649e9c440ab9457467fe04be25719a73e7c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 10 15:48:58 2013 +0100

    sna: Basic copy-on-write support for cloning pixmaps
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

:040000 040000 2891de17b5a1271fffbf71048055604b1aa0e678 9bbb332cf563e351cbf7924933bd701fcdbb1b2b M	src
Comment 1 Nick Bowler 2013-05-16 15:41:03 UTC 
Created attachment 79432 [details]
Xorg log
Comment 2 Chris Wilson 2013-05-16 21:31:57 UTC 
Can you double check that this appears to only affect zaphod?
Comment 3 Chris Wilson 2013-05-17 10:08:05 UTC 
commit 5d9315873e02d4acc5ddffc698dbf8984cbd5c42
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 17 10:51:44 2013 +0100

    sna: Avoid replacing pinned bo when undoing a clone
    
    Otherwise we end up cloning the scanout only to leave it dangling if the
    client copies the from the front-buffer and then writes to it.
    
    Reported-by: Nick Bowler <nbowler@draconx.ca>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64675
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 4 Nick Bowler 2013-05-17 13:28:31 UTC 
(In reply to comment #2)
> Can you double check that this appears to only affect zaphod?

Yes, I cannot reproduce the problem on an "ordinary" multi-head configuration.

Anyway, the mentioned commit appears to fix the issue, thanks!

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.