Created attachment 126486 [details] Screenshot to show tags and bar in window manager *awesome* Using Linux 4.8-rc5, with X.Org X Server 1.18.4, certain parts of the screen do not update right away. This happens in Xfce 4.12 [1] and the window manager *awesome* 3.5.9 [2]. 1. Changing a Firefox window from maximum to “reduced”/“normal” size, the part were the Firefox window isn’t present anymore, is still present. Switching between windows often fixes this. 2. In the window manager *awesome* the top bar is not updated when changing tags (think of virtual screen, although different). See the attached screen, which doesn’t show the problem, as doing the screenshot didn’t capture it, despite me seeing it. [1] https://www.xfce.org [2] https://awesomewm.org
If this is not the same as bug 90910, please attach the corresponding Xorg log file.
Created attachment 126513 [details] X server log file (In reply to Michel Dänzer from comment #1) > If this is not the same as bug 90910, please attach the corresponding Xorg > log file. I don’t think it’s the same bug, as I use the integrated graphics device from Intel with the X video driver *modesetting*. Please find the Xorg log file attached.
Are you using a compositing manager? If yes, which one, and what is its configuration? (In reply to Paul Menzel from comment #0) > 2. In the window manager *awesome* the top bar is not updated when changing > tags (think of virtual screen, although different). See the attached screen, > which doesn’t show the problem, as doing the screenshot didn’t capture it, > despite me seeing it. So the screenshot doesn't match the problem you were seeing? Did taking the screenshot also make the problem visibly disappear? If not, it sounds like it might be a kernel driver issue.
(In reply to Michel Dänzer from comment #3) > Are you using a compositing manager? If yes, which one, and what is its > configuration? I guess you mean something like Compiz? I am pretty sure I don’t. I use the plain awesome WM, or Xfce configuration. > (In reply to Paul Menzel from comment #0) > > 2. In the window manager *awesome* the top bar is not updated when changing > > tags (think of virtual screen, although different). See the attached screen, > > which doesn’t show the problem, as doing the screenshot didn’t capture it, > > despite me seeing it. > > So the screenshot doesn't match the problem you were seeing? Indeed. Unfortunately it does not. So when I switch to a different tag, the bar still contains the boxes from the Firefox windows, and not the terminal, for example. > Did taking the screenshot also make the problem visibly disappear? If not, it > sounds like it might be a kernel driver issue. No, it could still visually be seen. Drawing the box for ImageMagick’s tool `import`, some parts in the bar were visually a little corrupted, that means, the color of some pixel changed.
Created attachment 126547 [details] Example image with offset detected by GIMP Interestingly, opening the screenshot with GIMP it says that the PNG has an offset. > The PNG image you are importing specifies an offset of 192, 0. Do you want to apply that offset to the layer? Is that normal?
By default awesome uses a visual with depth=32 for all of its windows. AFAIK (someone who can reproduce this, please test), starting awesome with the --no-argb argument (= use the root window's visual) makes these problems go away. Also, AFAIK all kinds of screenshots show the correct data. Oh and once upon a time (but couldn't reproduce) I saw Xephyr having this problem, but moving the mouse pointer across the affected area of the tasklist made the expected/real content visible (at least for the part that the mouse pointer touched). I have no clue about the server, but this sounds like software cursor "fixing" things? Also, I could be mixing several different bugs which just have similar results. At least the depth=32 might be a useful hint. Paul, do you know if --no-argb works around these problems for you?
(In reply to Uli Schlachter from comment #6) […] > Paul, do you know if --no-argb works around these problems for you? Indeed, starting awesome with the switch `--no-argb` fixes the issue here.
Sounds like an issue with the automatic redirection of depth 32 windows then. Adam, any ideas?
*** This bug has been marked as a duplicate of bug 99220 ***
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.