| Summary: | Depth=32 not redrawn correctly (CopyArea has no effect) | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Uli Schlachter <psychon> |
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | ajax, alex.fellows, jan, pmenzel+bugs.freedesktop.org |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
*** Bug 97796 has been marked as a duplicate of this bug. *** *** Bug 90910 has been marked as a duplicate of this bug. *** As reported in #97796 this also happens with the Intel driver. Michael, should Adam be added to the CC list again? Finally caught a smoking gun: https://patchwork.freedesktop.org/patch/136721/ Alternative, lower level fix in the damage layer: https://patchwork.freedesktop.org/patch/137290/ 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/ 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.
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.