Description of problem: Often, a vertical band along the right side of windows is not being updated. It looks like the default background that X server draws when application stops updating. Triggering an update with mousing over forces the update. This happened between September 24 update and September 29. Version-Release number of selected component (if applicable): Difficult to identify what component is at fault. 9/29 update included many. Suspects: xorg-x11-server-common-1.5.1-2.fc10.x86_64 libX11-1.1.4-4.fc10.x86_64 cairo-1.8.0-1.fc10.x86_64 -- not likely, see below How reproducible: Happens all the time on the affected system. Unknown elsewhere. Steps to Reproduce: 1. Update Rawhide to listed above versions 2. Move two windows so they touch the right edge 3. Use wnck applet or Alt-Tab to switch, watch the right side Actual results: Dead, clipped areas Expected results: Normal refresh/update opon exposure. Additional info: Affected applications: Sylpheed, wnck-applet, Metacity. Looks like Firefox and gnome-terminal are not affected for some reason... In Metacity, buttons in window decorations disappear (but they continue to function if you aim a click into them). In wnck, some applications become invisible. Mousing over repaints because of tooltips. Also, it may be related: when the system boots, there's a band of garbage alongside the right side in splash backgrounds. It disappears after login (Nautilus is not affected, I guess). Severity is low, because applications remain functional. There's no crash. You just have to remember where the buttons and scrollbars are :-)
Created attachment 318122 [details] Screenshot (Metacity + Sylpheed) Notice that both Metacity and Sylpheed fail to repaint the same size band. Look at the upper right, where decorations and buttons are.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 318202 [details] xorg.conf
Created attachment 318203 [details] Xorg.0.log
Matej, are you serious about the autodetection above, or it's just your form letter? Sounds damn crazy to me.
Of course, it is a form letter. No, you're right -- autodetection doesn't make any sense here.
Oooh, indeed I was wrong. The ATI driver was updated: Sep 29 16:47:48 Updated: xorg-x11-drv-ati-6.9.0-18.fc10.x86_64 Component reassignment makes more sense now.
I've seen the same thing, except that it occurs in any window that is stretched past a certain width. I don't recall seeing it on another rawhide system that uses an intel graphics chip. It seems after the window gets more than 963 pixels wide some graphical elements stop updating. This seems to only affect elements drawn by Gnome/Gtk. KDE apps (I tested twinkle) only show the problem on the window title bar. In the GIMP the image I'm editing shows up just fine while the title and scroll bars and other elements are clipped.
Created attachment 319506 [details] Full desktop with the bug The unfortunate thing is, gvim is the hardest hit and I need it for work. The cut-off is 960 pixels off the left edge. In the screencap, there are three instances of it: 1. gvim (after ^L) <-- MOST IMPORTANT 2. wnck - see it shows only one GIMP window, but GIMP has two 3. notification area on top, little icons for scim and pidgin are absent
I'm seeing the same problem on my laptop with ATI RS690M "ATI Radeon X1200" (ChipID = 0x791f). I measured the same cut-off: 960 px Observed effects: invisible (but working) taskbar icons, missing icons in metacity buttons, a strip of random pixels on the right side of the screen in gdm, missing drawing in Firefox. Last known good version: xorg-x11-drv-ati-6.9.0-15.fc10.x86_64 First bad version: xorg-x11-drv-ati-6.9.0-16.fc10.x86_64 The bug is perfectly reproducible with the current xorg-x11-drv-ati-6.9.0-21.fc10.x86_64 too.
*** Bug 465280 has been marked as a duplicate of this bug. ***
*** Bug 466004 has been marked as a duplicate of this bug. ***
*** Bug 466061 has been marked as a duplicate of this bug. ***
*** Bug 465907 has been marked as a duplicate of this bug. ***
*** Bug 465832 has been marked as a duplicate of this bug. ***
*** Bug 465917 has been marked as a duplicate of this bug. ***
Created attachment 319756 [details] Diff between -15 and -16 I looked at the diff that Michal identified, but saw nothing objectionable.
BTW, 960 == 0x3c0. Looks like the VGA I/O address gets used as data.
*** Bug 465629 has been marked as a duplicate of this bug. ***
should be fixed in ati -24 or above in rawhide tomorrow.
I confirm 6.9.0-25 from Koji works for me.
I confirm that the problem is much better after updating today: xorg-x11-drv-ati.i386 6.9.0-25.fc10 But I'm still seeing some very similar problems with desktop icons. Every once in a while an icon will be corrupt but it will look ok if I wave the mouse over it.
Created attachment 320081 [details] screen shot of desktop icon corruption with 6.9.0-25.fc10
Confirmed -- updated ati driver fixed it for me too.
I would say, the icon corruption problem needs its own bug, to be freshly triaged. It's not necesserily the xorg-x11-drv-ati even.
*** Bug 466623 has been marked as a duplicate of this bug. ***
For another example of a display corruption see bug 466369 with a long list of screenshots to illustrate. Fedora 8 or 9 booted on the same hardware, and using the same configuration, does not show any issues. This is ATI on x86_64 for a change (and I do not observe that kind of problems like detailed in this report).