| Bug ID | 97796 |
|---|---|
| Summary | Parts of screen do not update |
| Product | DRI |
| Version | XOrg git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/other |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | pmenzel@molgen.mpg.de |
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 scree= n 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 =E2=80=9Creduced=E2=80=9D/=E2= =80=9Cnormal=E2=80=9D size, the part were the Firefox window isn=E2=80=99t present anymore, is still present. Sw= itching 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=E2=80=99t show the problem, as doing the screenshot didn=E2=80= =99t 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 corres= ponding Xorg log file.
Created attachment 126513 = [details] X server log file (In reply to Michel D=C3=A4nzer from comment #1) > If this is not the same as bug 90910, please attach the corres= ponding Xorg > log file. I don=E2=80=99t think it=E2=80=99s the same bug, as I use the integrated gr= aphics 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 wh= at is its configuration? (In reply to Paul Menzel from commen= t #0) > 2. In the window manager *awesome* the top bar i= s not updated when changing > tags (think of virtual screen, although different). See the attached s= creen, > which doesn=E2=80=99t show the problem, as doing the screenshot didn= =E2=80=99t 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=C3=A4nzer from comment #3) > Are you using a compositing manager? If yes, whi= ch one, and what is its > configuration? I guess you mean something like Compiz? I am pretty sure I don=E2=80=99t. 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 whe= n changing > > tags (think of virtual screen, although different). See the attac= hed screen, > > which doesn=E2=80=99t show the problem, as doing the screenshot d= idn=E2=80=99t capture it, > > despite me seeing it. >=20 > 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=E2=80= =99s tool `import`, some parts in the bar were visually a little corrupted, that mean= s, 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 off= set of 192, 0. Do you want to apply that offset to the layer? Is that normal?
By default awesome uses a visual with depth=3D32 for all of it= s windows. AFAIK (someone who can reproduce this, please test), starting awesome with the --no-argb argument (=3D 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 taskl= ist 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 resu= lts. At least the depth=3D32 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) [=E2=80=A6] > Paul, do you know if --no-argb works around thes= e problems for you? Indeed, starting awesome with the switch `--no-argb` fixes the issue here.<= /pre>
| What | Removed | Added |
|---|---|---|
| Product | DRI | xorg |
| CC | ajax@nwnk.net | |
| Version | XOrg git | unspecified |
| QA Contact | xorg-team@lists.x.org | |
| Component | DRM/other | Server/Ext/Composite |
| Assignee | dri-devel@lists.freedesktop.org | xorg-team@lists.x.org |
Sounds like an issue with the automatic redirection of depth 3= 2 windows then. Adam, any ideas?