Bug 99220 - Depth=32 not redrawn correctly (CopyArea has no effect)
Summary: Depth=32 not redrawn correctly (CopyArea has no effect)
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
: 90910 97796 (view as bug list)
Depends on:
Reported: 2016-12-29 14:50 UTC by Uli Schlachter
Modified: 2017-05-23 15:34 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Description Uli Schlachter 2016-12-29 14:50:20 UTC
The window manager called awesome by default uses depth=32 for its windows. This causes the following problem. When starting with the argument `--no-argb` which makes it use the root's depth and visual instead, the problem does not occur.

* Start awesome
* Start a terminal (Mod4+Enter in the default config)
* Switch to tag 2 ("tag"="workspace"; Mod4+2 in the default config)
* Notice that the taglist at the top of the screen now has "2" highlighted
* Switch back to tag 1 (Mod4+1)
* Notice that the taglist *still* has the "2" highlighted

When one now moves the terminal over the taglist (click+drag on the titlebar), the exposed areas are redrawn correctly.

Awesome draws to a pixmap and when done does a CopyArea request to update the window. Expose events are handled in the same way.

I have several reasons to think that this is a bug in the server:

* `--no-argb` / using the default depth and visual makes the problem go away
* Exposure shows the expected content, hence the pixmap used for double buffering has the right content
* People reported that switching video drivers caused the problem or made it go away.

Also, the following "patch" fixes the problem. The effect of the patch should be to update all windows with automatic redirection (depth=32, but parent has another depth) needlessly all the time. The word "needlessly" here shows that something is wrong, but I cannot figure out what (the patch should not make a difference, but it does!). The damage extension seems to report things correctly, but still the composite extension code sees an empty damage area...

diff --git a/composite/compwindow.c b/composite/compwindow.c
index bcd230c37..913882618 100644
--- a/composite/compwindow.c
+++ b/composite/compwindow.c
@@ -696,7 +696,7 @@ compWindowUpdateAutomatic(WindowPtr pWin)
      * Clip the picture
-    SetPictureClipRegion(pDstPicture, 0, 0, pRegion);
+    //SetPictureClipRegion(pDstPicture, 0, 0, pRegion);
      * And paint
@@ -724,7 +724,7 @@ compPaintWindowToParent(WindowPtr pWin)
     if (pWin->redirectDraw != RedirectDrawNone) {
         CompWindowPtr cw = GetCompWindow(pWin);
-        if (cw->damaged) {
+        if (1 || cw->damaged) {
             cw->damaged = FALSE;

This is a forwarding of at least the following bugs, the oldest of which is 1.5 years old:


I'd be more than happy to help debugging this, but I am out of idea to try. Myself, I can only reproduce this with Xephyr, but others have had this happen, for example, with Xorg and vboxvideo or radeon.
Comment 1 Michel Dänzer 2017-01-18 08:55:35 UTC
*** Bug 97796 has been marked as a duplicate of this bug. ***
Comment 2 Michel Dänzer 2017-01-18 08:55:51 UTC
*** Bug 90910 has been marked as a duplicate of this bug. ***
Comment 3 Paul Menzel 2017-01-18 09:06:58 UTC
As reported in #97796 this also happens with the Intel driver.

Michael, should Adam be added to the CC list again?
Comment 4 Michel Dänzer 2017-02-03 08:36:55 UTC
Finally caught a smoking gun: https://patchwork.freedesktop.org/patch/136721/
Comment 5 Michel Dänzer 2017-02-07 08:40:29 UTC
Alternative, lower level fix in the damage layer: https://patchwork.freedesktop.org/patch/137290/
Comment 6 Paul Menzel 2017-02-07 09:38:06 UTC
Michael, I only tested the second patch, and it worked for me with the X.org server 1.18.4. Awesome! Thank you very much.

[1] https://patchwork.freedesktop.org/patch/137290/
Comment 7 Adam Jackson 2017-05-23 15:34:36 UTC
commit 38696ea56854e055c31bd2730adfc7c39aa115b0
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Feb 7 17:38:23 2017 +0900

    damage: Validate source pictures bound to windows before unwrapping
    The lower layers also do this, but no damage may be reported there,
    since we unwrap before calling down.
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99220
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

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.