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) {
             compWindowUpdateAutomatic(pWin);
             cw->damaged = FALSE;
         }


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

https://github.com/awesomeWM/awesome/issues/1322
https://github.com/awesomeWM/awesome/issues/925
https://github.com/awesomeWM/awesome/issues/264

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.