It's not random, as described in

https://bugs.kde.org/show_bug.cgi?id=197602

and

https://bugs.kde.org/show_bug.cgi?id=184314

There also are videos on both the above links that show the effect.

If you have multiple toolbars, go to one of them and wait for a tooltip to pop up. Then go to the second toolbar and wait for the tooltip. The area in which the first tooltip was displayed is then corrupted and the desktop background becomes visible just in that space.

I have this problem on a ThinkPad X200 which has an Intel graphics card with KMS enabled. With desktop effects enabled, this doesn't happen. It happens with effects turned off for me. But there are others in the KDE bug tracker who say acceleration doesn't seem to matter.

I can confirm  that bug like Amit Shah described it. Please fix it, it’s sooo annoying -.-

still there with xorg-1.7.5

Its really annoying, please fix it :/

I am still seeing this bug in Ubuntu 10.04, Xorg 1.7.6 and KDE 4.5.1 with the fglrx driver.

Same thing with Debian squeeze, Xorg 1.7.7 and KDE 4.4.5.

This bug has existed for ages with all KDE4 versions and all Xorg drivers (I tested various intel driver versions, the radeon driver, the fglrx driver and the nvidia driver).  For drivers that support KMS, enabling or disabling KMS does not make this bug disappear.

Therefore I guess that this bug is in a core part of the server.

This is happening to me with composite disabled. Perhaps this can be confirmed by someone with more background on xorg/kde and so bug title could be updated with more confidence.

Confirming it affects me too, all KUbuntus since Jaunty till Lucid, probably will go to Maverick. Compositing should be disabled (enabling KWin effects removes the problem, but it is slow due to my video card).
KDE 4.4.2, X server 1.7.6
The graphical trash can be reproduces exactly as it is described in the comment 1.
Tested with intel and nvidia graphics.

I wonder why this bug lives so long - it constantly moves from one distribution to another. It just becomes more and more annoying due to its survivability.

> I wonder why this bug lives so long - it constantly moves from one distribution
> to another. It just becomes more and more annoying due to its survivability.

I guess its because of:

- Two projects are involved, KDE and Xorg. This already led to the usual finger pointing. This way no problems are fixed.

- Its quite hard to reproduce. I also get this corruptions, but can't trigger then as easily as shown in the KDE bug reports.

- KDE isn't *the* major desktop environment anymore, it has become an alternative to gnome for most distributions. So distributors don't care enough to pay somebody to track this bug down and fix it.

(In reply to comment #7)
> - Two projects are involved, KDE and Xorg. This already led to the usual finger
> pointing. This way no problems are fixed.
> 
> - Its quite hard to reproduce. I also get this corruptions, but can't trigger
> then as easily as shown in the KDE bug reports.

It would help for these issues if there was a simplified test program (not using Qt but direct X calls) reproducing the problem. That should help demonstrating that it's indeed a bug in X as well as fixing it.

(In reply to comment #8)
> It would help for these issues if there was a simplified test program (not
> using Qt but direct X calls) reproducing the problem. That should help
> demonstrating that it's indeed a bug in X as well as fixing it.

I feel it is just not realistic to expect such a thing from usual users, which are not involved in the development of KDE/Qt/X. If it is what the developers are waiting for, then the problem will never be fixed, most probably. Obviously, the graphical corruptions that we a speaking about require some rare conditions to meet together, and thus would hardly occur in a simple app. If someone can provide such a simple test app for this rather complicated bug then he already knows the source of the problems himself and probably understands how to fix it. Then he can just say how to fix it. Thus, this essentially means to wait until some external person find a fix for the bug.

Spent quite some time trying to create an XLib-only testcase, found out by accident that the problem seems resizing/moving unmapped ARGB32 windows.

The testcase attached demonstrates the issue, in a few seconds I have a desktop full of perforated windows, regardless of the windowmanager used.
Running a composition manager makes the problem disappear for me, just like as for KDE.

I've also recorded a short video: http://www.youtube.com/watch?v=_d9DCEAZfNA

Created attachment 38941 [details]
Xlib only testcase

I can reliably reproduce the bug using the attached test case on my system.

(In reply to comment #11)

Cool, it works!

(In reply to comment #10)
> Spent quite some time trying to create an XLib-only testcase, found out by
> accident that the problem seems resizing/moving unmapped ARGB32 windows.

Thanks Clemens, this looks very helpful.

Trying to get the attention from the 1.9 release managers / the author of the Composite extension.

Thanks Michel for taking care of this bug :)

Note that on a quick test I couldn't seem to reproduce the problem with Clemens' test case on recent xserver Git. Has anyone reproduced the problem with xserver 1.9.x or even 1.8.x?

Yes, I use openSUSE 11.3 which has server 1.8.0 and see the problem when I run a non-compositing window manager (KWin with compositing disabled) while the compositing extension is enabled (which is the default when you have no xorg.conf).

I can reproduce the problems on "X.Org X Server 1.8.2"

I did reproduce the problem with X.Org 1.9.0 on new Kubuntu 10.10 RC as well as on OpenSuse 11.3, which is 1.8.x I suppose.

How to reproduce the bug reliably is described in https://bugs.kde.org/show_bug.cgi?id=253078 . That bug was closed as duplicate of this bug.

I get this bug only when composition is disabled contrary to what main heading says.

dmatt, don't confuse "compositing" and "composite extension" enabled :)

(In reply to comment #20)
> dmatt, don't confuse "compositing" and "composite extension" enabled :)

Everyday I learn something new :)
Yes I am the case of disabled compositing and enabled compositing extension.

so, any idea what could cause this?
It looks like expose events are sent to the wrong windows somehow.

I am beginning to doubt that the bug is indeed in X, because I can not reproduce it in pure X (without KDE or any other DE and any window manager, starting it via xinit).
The holes in application windows and various graphical elements can appear only after I launch manually 'plasma-desktop' (this loads desktop and panels, but still no window manager). This suggests the bug may be actually located in plasma. Is it reproducible using the Clemens' testcase in something else than KDE (e.g. gnome)?

I can reproduce the problem with icewm too, and I doubt plasma is involved in this problem at all - it hasn't any way to influence the expose-handling of windows.

Created attachment 39341 [details]
windows "holed" under icewm

(In reply to comment #23)
> I am beginning to doubt that the bug is indeed in X, because I can not
> reproduce it in pure X (without KDE or any other DE and any window manager,
> starting it via xinit).
I can reproduce this with just X, twm xterm and xeyes as well as the testcase attached to this bug (started several times to get holes faster). With the client areas of xeyes and xterm overlapping, the test case app causes the contents of the xeyes window to be painted over the xterm window in front of it.
I used a pretty much empty xorg.conf containing just stub sections, so no extensions have been disabled/enabled.

It took me a really longt ime to come up with this testcase, as it has been requested.
Now there is a testcase, triggering the problem on many machines and still no progress :/

I noticed a subtile thing, windows located at (0,0) don't seem to be affected by the corruptions.

As sson as I move firefox away from the top-left corner, I see the artifacts - as soon as I move it back no new artifacts appear.

In my KDE 4.4.2 the windows at (0,0) can be corrupted just as easily.
Actually I noted the following rule (in KDE): the corruption (a hole in the place where some old tooltip was previously drawn) occures only if the new tooltip (the one which triggers the hole) does NOT cover the window which should be holed. Due to this, the maximized windows are never holed by KDE tooltips. But this rule seemingly does not apply to your testcase: it corrupts just all existing windows.

I was able to reproduce the bug with xorg-x11-server 1.9.99.1-2.20101201 shipped as part of Fedora rawhide. 

Just download the KDE live cd, and start the holer testcase.

please(!!!!) someone try to fix this bug. who maintains the responsible code part?

Well, this bug is still around for me.  I initially reported it to KDE as
https://bugs.kde.org/show_bug.cgi?id=267641

I have upgraded to KDE 4.6.2 since reporting the bug, but it's still here.

here for me to. at least it has been moved from 1.9.x blocker bugs to 1.10.x, so hopefully it will get some attention.

I cannot reproduce this bug in KDE 4.6.2 (XOrg 1.10.1) with KUbuntu Natty during the routine work. The action sequences that previously corrupted panels and windows with 100% chance, no longer corrupt anything. I tested this on two machines, with intel and nvidia graphic cards. I am really happy not to see these corruptions now.
However, the holer testcase from here still corrupts the desktop as previously. This may indicate that the bug is not really fixed and can re-appear again in future releases.

After a couple of months of working with KUbuntu Natty I find that these graphical corruptions still may occasionally appear (mainly the panels get corrupted). However, they became very seldom, and I cannot figure out how to reproduce them "naturally" (not using the testcase from here). The testcase still works as previously.

Please test with xorg-server-1.11.1.  We believe that this is probably fixed in 1.11.  If there is no response in the next month, this issue will be closed as presumed fixed.  See http://lists.freedesktop.org/archives/xorg/2011-September/053561.html

I can still reproduce the problem with 1.11.0, shipped with Fedora-Beta-RC3.
There is a simple, self-containing test-case attached, so developers should be able to reproduce the issue themself easily.

Please change bug status to "New" again.

Over to Ville

Just posted a fix to the mailing list: http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/25664

This has been merged to the 1.11 branch and will be in 1.11.2 RC2