Bug 170462

Please excuse the formatting. I suck.

*** Bug 172439 has been marked as a duplicate of this bug. ***

I have this on both my ATI machines...

Running intrepid ppa's.

Could you please provide an update for this bug?

Rgs
Steve

Yes, it occurs at my system also, KDE 4.1.2 in Ubuntu Intrepid. I am using Nvidia 177.80 driver.

Some screenshots (taken at monent when window appears) attached.

Created attachment 28140 [details]
KDE composite garbage screenshot

Created attachment 28141 [details]
KDE composite garbage screenshot

Firefox appearing on screen

Created attachment 28151 [details]
Video showing garbage

This is a short video which shows the kind of garbage I see when clicking the first time on the kickoff menu, after KDE startup.

You'll notice that the second click draws the menu without garbage.

If I had to guess as to what was wrong, I'd think that a surface or pixmap isn't being properly cleared or initialized before being used.

Same here. Apparently an xdamage event causes a repaint before the app was able to actually paint. Most striking is it when opening a new menu, but firefox also shows it 'really well'.

Is this the same issue that affects Gwenview? (note: compositing disabled over here...)

Hi,


Anynone can provide a feedback for this bug?
I've upgraded to Fedora 10 and kde4.1.3 and The issue now appears at random 
even when I drag the windows...

Regards
Steve

Occurs for me using Kubuntu 8.10 aka KDE 4.1 using 'intel' graphics drivier.
According to the Launchpad bug, graphics driver/chip set isn't a factor.

Original reporter here. Yves Glodt's video a few replies up depicts the video garbage exquisitely. 

I've tried it on another three machines now, two of which with Intel chipsets and the third with an Nvidia card (using both nv and nvidia drivers), all exhibiting the same results. This was with KDE 4.1.3 from the Intrepid backports repository, have not tried newer builds yet.

It's a _very_ saddening smudge on an otherwise beautiful environment. :<

*** Bug 169106 has been marked as a duplicate of this bug. ***

(In reply to comment #14)
> Original reporter here. Yves Glodt's video a few replies up depicts the video
> garbage exquisitely. 

There is a duplicate of this bug which has a screenshot attached which quite exactly shows what I demonstrated in my video.

Bug is http://bugs.kde.org/show_bug.cgi?id=169106
Attachment is http://bugs.kde.org/attachment.cgi?id=27830



> I've tried it on another three machines now, two of which with Intel chipsets
> and the third with an Nvidia card (using both nv and nvidia drivers), all
> exhibiting the same results. This was with KDE 4.1.3 from the Intrepid
> backports repository, have not tried newer builds yet.
> 
> It's a _very_ saddening smudge on an otherwise beautiful environment. :<
> 

I have to disagree with http://bugs.kde.org/show_bug.cgi?id=169106#c7
The latest nvidia driver does not solve the problem. There is a display issue with firefox/thunderbird which is resolved by this driver. 

However, the bug remains unresolved for KDE4-Apps and it is not limited to nvidia cards. 

Also I'd like to point out that this is a very real security issue. The "garbage" displayed is actually video memory and seeing chunks of expired windows when opening a completely different window minutes or even hours later can lead to very grave consequences in various work environments. 

It doesn't take a lot of imagination to construct cases where this is a very bad thing. (And yes, it already happened to me so please, *please* fix that. I really don't want to go back to KDE 3)

(In reply to comment #17)
> I have to disagree with http://bugs.kde.org/show_bug.cgi?id=169106#c7
> The latest nvidia driver does not solve the problem. There is a display issue
> with firefox/thunderbird which is resolved by this driver. 

For me, the latest nVidia beta driver fixes these issues, but I had to revert to the latest stable release because it kept crashing my system.

I agree with you on this being a pretty serious security/privacy issue since this also happens (on my system) with the desktop locking screen – you can often see the contents of the active session almost undistorted before actually unlocking the screen.

David - if it is a video driver bug, it's present in a wide verity of them as I'm on an Dell laptop using the 'intel' X driver.
Maybe your new driver just does something slightly differently, timing wise, and that is hiding it.

(In reply to comment #19)
> David - if it is a video driver bug, it's present in a wide verity of them as
> I'm on an Dell laptop using the 'intel' X driver.

You're right, I have completely missed that point.
But for whatever reasons, the new driver really helps. Maybe it is just clearing the video memory when allocating new textures or something like this (this is just a wild guess).

(In reply to comment #8)

I see the same on another laptop which has a dedicated ati mobility 9700 chip. The "garbage" looks a little bit different, but overall it is the same. I run ubuntu intrepid with kde on it, and installed gnome as well, and in gnome I do not see the effect.

I experience this problem too with Kubuntu 8.10 with KDE 4.1.3. ATI Radeon Xpress 200M chip with proprietary fglrx driver.

I experience this issue with KDE 4.1.3 on a Dell XPS m1330 laptop with Intel video card. I think this bug is terrible because it prevents me to use my laptop with KDE 4 for presentations; I have to login in Gnome or even use another laptop with another OS whose name I will not say.

Exactly the same for me ... Please advise
Anyone from the dev to provide any feedback on this?

Rgs
vouchy

*** Bug 173466 has been marked as a duplicate of this bug. ***

I have been doing some testing on this and I think it is related to the 'Scale In' plugin.  I cannot reproduce with it disabled.

Nvidia 180.06 and a recent svn build of KDE.

*** Bug 163652 has been marked as a duplicate of this bug. ***

(In reply to comment #26)
> I have been doing some testing on this and I think it is related to the 'Scale
> In' plugin.  I cannot reproduce with it disabled.
I don't have this effect enabled and I am experiencing the video garbage nevertheless. But it is an idea and I'll try if disabling fade plugin helps for me.

Is it possible that it is something in the animation framework which is showing up in multiple plugins?  I disabled everything, then started re-enabling everything one by one.  Scale In is the only one that I can reliably reproduce with.

This bug appeared at almost exactly the same time as r855784 and r854690 were committed to scale and they affect the same types of window, I haven't tried if reverting those changes fixes anything.

My plugins are zoom, fade, login, logout, magic lamp, shadow, translucency, wobbly, snow, dialog parent, dim administrator, cube and present windows.  I cannot see the bug at all until I enable scale in.  Then I can see it all the time.

Turning off 'enable desktop effects' fixes it for me, but obviously removes a lot of the nice eye candy.
Even having this option on, with none of the effects boxes ticked, Firefox's history menu and bookmarks menu (for instance) shows garbage (if you move the mouse betwen them. Ditto Konsole. What I think you are seeing is that with (less) effects on, the garbage is visible for less time so harder to see/trigger.

My list of effects: Dim, zoom, fall apart, login, logout, scale, translucency, wobbly, taskbar thumbs

For me the video garbage was worse with 'enable desktop effects' turned off, especially on the Shutdown confirmation dialog (when it fades the screen to grey). Instead of fading the screen, it would show almost the entire contents of the last open window (even when the application had been closed), only slightly garbled but still very legible. Obviously not a good thing if for example, I just closed my online banking site (I'm sure others can think of other bad situations ;-)).

However, since I upgraded to the Nvidia 180.11 driver, I no longer experience ANY video garbage (whether using desktop effects or not). However the system tray transparency bug still remains (which I hear is to be fixed in KDE 4.2).

As some people have mentioned they are still experiencing the video garbage with Nvidia 180.06, perhaps they could try with 180.11 and see if it is still there? However, as people with Ati and Intel cards have also reported this, perhaps multiple bugs are being confused as the same issue, or at least showing the same symptoms?

On my machine running the KDE 4.2 beta 1 (kubuntu.org ppa) and intel driver, disabling Desktop Effects doesn't help. Using Compiz in favor of kwin, however, makes it noticably much less prevalent.

If it goes away completely with newer Nvidia drivers then it strikes me as some Qt4/kwin/X/* quirk that Nvidia somehow found a workaround for, or otherwise invalidated.

I confirm that nvidia drivers version 180.11 seems to fix the problem on my GeForce 7050/nForce 610i (rev a2), where version 177.80 previously did show the problem. Tested with 4.1.3 (kubuntu intrepid) and current svn, with and without desktop effects enabled.

I have just updated to 180.16 and I still am seeing flashes of corruption with the scale in plugin.  Maybe this is actually 2 bugs?  I can still reliably reproduce by quickly opening and closing Firefox menus.

I cannot see the problem with other windows (ie. tooltips) though, just scale in and Firefox menus.

Should I report this as another bug?

I confirm no problems on my system (details in comment #33) with the scale in effect, or firefox menus.

I noticed that this bug only occurs to me on Kubuntu. (With 'this bug' I'm referring to the screenshots I posted in bug 169106.) I tried OpenSuse and Debian, no video garbage. This lead me to think this bug was in a part of the distribution, not KDE. To try to prove this, I installed Debian unstable's Xorg on Kubuntu Intrepid with KDE 4.2b2 from PPA. This, surprisingly, seems to work without seeing this bug. Using Kubuntu's Xorg I can see black and garbaged menu's when moving quickly between them in Konqueror. Using Debian's Xorg, it works perfectly. With or without compositioning.

For anyone wanting to reproduce this. Add a line for Debian unstable to /etc/apt/sources.list then install Debian's Xorg with 'aptitude install xorg=1:7.3+18 xserver-xorg=1:7.3+18 xserver-xorg-core=2:1.4.2-9'. I'd like to warn everyone, this WILL damage your installation. (I used VM's.)

Hope this helps someone solve this very irritating bug.

Oh, I can also confirm that Nvidia's latest beta driver (180) solves this bug on my laptop. 

well, I'm on an intel card.
The bug is present in kubuntu hardy/intrepid, (kde 4.0/kde 4.1) fedora 10 (kde 4.1), but not in opensuse 11.0/11.1 (kde 4.0/kde4.1/kde4.2beta2).
I just want to point that, even if opensuse seems to be not affected by this bug there is still a lot to be improved around, when starting new programs (opening programs leads to an empty window that gets repainted with the content), when resizing (garbage everywhere :( ), when switching sections in system settings, when opening a picture in gwenview (garbage while loading the picture).
Well....it's such an hard situation! :|

One more data point:

- Mine is an Intel video chip (so it can't just be NVidia related)
  Here's the hardware data from /var/log/Xorg*log

(--) PCI:*(0@0:2:0) Intel Corporation 82G33/G31 Express Integrated Graphics Controller rev 2, Mem @ 0xfdf00000/0, 0xd0000000/0, 0xfdd00000/0, I/O @ 0x0000ff00/0

- The most reliable way to reproduce this in my env is by opening a new Firefox window (CTRL-N in Firefox)

- Problem first occurred after upgrading to Intrepid Ibex (KDE4 / Kwin)

HTH

Inspired by comment #36 I did some testings today. As basis I used a notebook with Intel graphics and installed Debian Lenny (testing) with KDE 4.1. I tried the usual things to get video garbage: open iceweasel, use krunner, open menus, contextmenus etc. I did not see any video garbage.

Now I tried on the same notebook Kubuntu 8.10 from a live cd. I installed firefox. Started and: video garbage. Also Kickoff and menus showed video garbage, but not as bad as my nVidia system.

I just searched for the main difference: xorg. Debian is using xserver-xorg in version 7.3 (http://packages.debian.org/lenny/xserver-xorg), (K)ubuntu is using version 7.4 (http://packages.ubuntu.com/intrepid/xserver-xorg).

Users from Fedora and OpenSuSE. Which xorg versions are included in your distributions?

After reading comment #39 I decided to try to install Debian experimental's Xorg on Kubuntu Intrepid. This works, without any garbage. As can be seen at http://packages.debian.org/source/experimental/xorg this is Xorg version 7.4.

OpenSuSE 11.1 runs without any garbage using Xorg 7.4. See the feature list at http://en.opensuse.org/Featurelist_11.1

Martin,

If you copy the Kubuntu xorg.conf to Debian does the problem start occuring?

(In reply to comment #40)
> After reading comment #39 I decided to try to install Debian experimental's
> Xorg on Kubuntu Intrepid. This works, without any garbage. 

Could you please detail the steps you took to do this? I'm interested in trying to reproduce it.

(In reply to comment #42)
> (In reply to comment #40)
> > After reading comment #39 I decided to try to install Debian experimental's
> > Xorg on Kubuntu Intrepid. This works, without any garbage. 
> 
> Could you please detail the steps you took to do this? I'm interested in trying
> to reproduce it.
> 
First step is to add the Debian Experimental repository to your /etc/apt/sources.list . A line like 'deb http://ftp.nl.debian.org/debian experimental main' will do that. (You can change the 'nl' to any other Debian mirror.) Hit a 'sudo aptitude update' after that. It'll download the list of packages from Debian Experimental.

To install Xorg I used the following command:

sudo aptitude install xorg=1:7.4~4 xserver-xorg=1:7.4~4
xserver-xorg-core=2:1.5.3-1 xserver-xorg-video-vmware=1:10.16.5-1
xserver-xorg-video-vesa=1:2.0.0-2 xserver-xorg-input-evdev
xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-video-all
xserver-xorg-input-all

I got the version numbers from http://packages.debian.org/ . Note that you can play a bit with which drivers to install. I first tried to install without specifying the drivers but aptitude told me that wouldn't work. So I specified the drivers manually. And after that I found that I just had the install the xserver-xorg-*-all packages. So before letting aptitude install, just make sure it installs everything you need (like the X video and input drivers you need).

After aptitude is finished, restart X by rebooting, pressing CTRL+ALT+BACKSPACE or restarting kdm. (I rebooted, but the other two methods should also work.)

Again, a warning to everyone wanting to try this, it WILL damage your system if you don't know what you're doing.

I've been doing some testing yesterday and today. I tried rebuilding xserver-xorg-core without some Ubuntu/Fedora specific patches. I've found that a build of xserver-xorg-core without the '107_fedora_dont_backfill_bg_none.patch' patch doesn't have any video garbage.

If you want to reproduce this, follow these steps (tested on Ubuntu Intrepid):

apt-get build-dep xserver-xorg-core
apt-get source xserver-xorg-core
Edit xorg-xserver-1.5.2/debian/patches/series and put a '#' in front of the line '107_fedora_dont_backfill_bg_none.patch', save the file.
cd into xorg-xserver-1.5.2
dpkg-buildpackage -uc -us  # You can use -j on dual/quad core machines
cd up one folder
install the created deb's
restart X

And there it is folks. With such as obvious patch filename like that it should have been found earlier. =)

Can you please file this bug with the distributions that use the patch. Might be an idea to link them directly here and mention that not applying that patch fixes it to save them some time.

Confirming, no garbage after compiling my own xserver-xorg and installing the bunch of .debs it spouts out. Yay~! :3

One minor question, semi-related; how do I increment the package versions so that update managers don't insist on replacing them with the repository versions? I can tell aptitude to hold them, but Adept has its own ideas.

I opened a new bug at launchpad with request to remove the patch: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/310228

Googling for that patch name leads to this blog posting hinting that nvidia knew about the problem and work around it in their driver :-(
http://sayakb.blogspot.com/2008/11/choppy-choppy.html

I am running Gentoo and I cannot see any patch which mentions backfill.  I checked through all of the files and none of them are commenting the same lines out.

Could this be a different bug for me?  The description matches exactly.

*** Bug 169106 has been marked as a duplicate of this bug. ***

(In reply to comment #48)
> Googling for that patch name leads to this blog posting hinting that nvidia
> knew about the problem and work around it in their driver :-(
> http://sayakb.blogspot.com/2008/11/choppy-choppy.html
> 

That's open source for you. >.<

(semi-spam since it's not completely bug related, but had to be said!)

Confirm the steps in #44 work a treat, hurrah !

Hi,

I am running Fedora 10. How Can I fix it for this distribution?

Rgs
Vouchy

After speaking with fedora's X maintainer, I am not convinced that suggesting downstream removal of the aforementioned X server patch is the best way forward.

Now, my X-protocol-fu is lacking, so some of this is beyond my current complete understanding, but ajax outlines what seems to be another sensible fix/workaround:

 <rdieter> ajax: got a sec to comment on the origins of 107_fedora_dont_backfill_bg_none.patch , and how it relates to http://bugs.kde.org/show_bug.cgi?id=170462 ?
 <ajax> it's a performance hack for compositing
 <ajax> the problem is that windows can have their background pixmap set to "None", which means something vaguely like "don't draw a background at all, just reuse the bits underneath wherever the window got mapped"
 <rdieter> it seems to have side effects...
 <ajax> no kidding!
 <ajax> in Composite there's no strong notion of "the bits underneath where you got mapped"
 <ajax> since the compositor could map you anywhere
 <ajax> trying to do what the protocol says is intensely painfully slow since it's a readback from the card and those aren't fast
 <ajax> so what gnome quite sensibly does is tells the compositor not to show the window contents until they're painted, using the same sync protocol that window resizing uses.
 <ajax> and then the server just doesn't define initial window contents when the window is both redirected and bg=None
 <rdieter> so it wouldn't be wrong to assert there's an issue/buglet here (in kde) still, and the xorg patch is simply helping to expose it?
 <ajax> it's sort of ugly no matter what you do, which is why we're still carrying that patch four releases later instead of having it upstream.  anything you do here is wrong.
 <ajax> you're either breaking protocol semantics that have been good for twenty years, or you're screwing performance.
 <ajax> rdieter: i'd say kde should do the sync protocol for mapping here, yes.  it'll make it look right on servers with this hack, but it'll also look better on unpatched servers since you won't see the menu in mid-draw


And another alternative:
 <mclasen> ajax: is this something you could negotiate at connection setup ?
 <ajax> mclasen: mm.  possibly.
 <ajax> you'd need to fix the toolkits to ask for protocol 11.1, i suppose.
 <mclasen> ajax: alternatively, invent a new NONE-I-MEAN-IT special value
 <ajax> yeah.  composite could define a magic pixmap that meant suppress-backfill instead of the historical None value
 <ajax> and then the server would just treat it like None when the window wasn't redirected.
 <ajax> that's not the worst idea ever.
 <ajax> and if we're doing that, we should probably just return the CompositeNone pixmap in the CompositeQueryVersion reply so you skip a round trip.



p.s. Apologies for longish-quasi-spam-to-bugzilla here

Thanks for the input. I guess we have to work on it. But I don't think we will have the changes ready for 4.2 (tagging of 4.2 is in about three weeks).

So basically for 4.2 we have the following situation: KDE looks good on distributions without that patch, looks bad for distributions with that patch. I think it's up to the distributions to decide what they want to have.

np, and thanks to all for the excellent detective-work, took quite a bit of time and effort to get to where we are now.

(In reply to comment #56)
> np, and thanks to all for the excellent detective-work, took quite a bit of
> time and effort to get to where we are now.
> 

Two long evenings on my part. No problem BTW, it was fun to do :)

Is it known which parts of KDE need to be changed in order to work correctly on patched servers? Qt, KWin, something else?

https://bugs.kde.org/show_bug.cgi?id=155808 may be related - those bugs have one in common - something odd is being drawn before actual window appears.

Disabling ARGB glx visuals in xorg.conf (Option      "AddARGBGLXVisuals" "No") "solved" the problem for me (well, it disabled compositing in the process, but solved this issue for 'no compositing' as well).

(In reply to comment #55)
> Thanks for the input. I guess we have to work on it. But I don't think we will
> have the changes ready for 4.2 (tagging of 4.2 is in about three weeks).
> 
> So basically for 4.2 we have the following situation: KDE looks good on
> distributions without that patch, looks bad for distributions with that patch.
> I think it's up to the distributions to decide what they want to have.

It's worse, actually. From casual testing, I'm seeing a considerable performance hit with a "non-patched" xserver (the one you posted on your blog). Opening menus in quick succession now suffers from visible lack in painting. So it looks like, as ajax already noted:

- bad performance, but no garbage shown
- garbage shown, but good performance

Thanks everyone, as I think it's a little too late for 4.2.0 hopefully we can get it into 4.2.1 instead.

(In reply to comment #60)

> It's worse, actually. From casual testing, I'm seeing a considerable
> performance hit with a "non-patched" xserver (the one you posted on your blog).
> Opening menus in quick succession now suffers from visible lack in painting. So
> it looks like, as ajax already noted:
> 
> - bad performance, but no garbage shown
> - garbage shown, but good performance
> 

Sebastian: I'm using the patched server on Intrepid  from

deb http://ppa.launchpad.net/adamspain/ubuntu intrepid main

and I can't see that performance hit you're talking about. The garbage seems gone and the speed is almost the same (or maybe even a little better)

I'm using KDE 4.2beta2 from Kubuntu packages and an Intel chipset

I'm using a stock Kubuntu 8.10, with the (un :-))patched Xorg. And performance is the same, just no garbage.
Sebastian, did you build your own X or use the PPA one ? 
Lucas, is there no way this can get into 4.2 ? It's killing the look of KDE...

Hmm, there are two weeks until RC 1 is tagged. Anything added after Jan 6th will not be in 4.2.0.

Technically, we can add or revert patches until roughly 20 January (6 Jan is tagging of the release candidate), although earlier is obviously better to catch errors.

Right now, there's not even a patch to KDE, though, so it cannot even be reviewed or tested. In any case, we should try to get this sorted ASAP.

Created attachment 29583 [details]
Firefox after removing 107_fedora* patch on Kubuntu 8.10

I've noticed this *after* following comment #44. Although the garbage is removed, I've begun to notice the following distortions of Firefox text.

I've began to notice this in Firefox after following comment #44. Although everything so far *after* following comment #44 seems fine, could the following be a side-effect? https://bugs.kde.org/attachment.cgi?id=29583 . I am not sure what to do or if this is really related. The text distortion in firefox goes away if I highlight the page but it seems to return if the page loses focus. Could this be a side-effect? Is it related?

I dont have this distortion. Can you always trigger it at the same URL ?

I don't get any such distortions either.

So far I've seen no adverse effects from disabling said patch. I get the same (poor) glxgears framerate (from contemporary pre-GEM, identity crisis intel X drivers). That said, I *have* encountered some remnant video garbage, drawn on the desktop workspace.

If I use maximized applications for a while (hiding the desktop) and then manage to uncover a part of the desktop by minimizing something and giving focus to a "normal" window in a restored (not mini-/maximized) state, there is persistent garbage covering the desktop, or at least an area of it. This does not go away by itself unless I click the desktop itself. It happens rarely so I haven't yet tried other actions, like moving other windows across the garbage to see what that produces.

I will try to take a screenshot when it happens next.

Created attachment 29675 [details]
Persistent video garbage covering whole desktop

Attached an image showing the aforementioned persistent desktop garbage. It started out behind one window, becoming visible when I minimized/closed it. Moving any other window at this point created more garbage in the window's wake, until at last I had filled the entire desktop area.

JR - this is with the KDE 3.2 beta right, not the actual 8.10 release ? I don't see your problem here...

(In reply to comment #71)
> JR - this is with the KDE [4.2] beta right, not the actual 8.10 release ? I don't
> see your problem here...
> 

Yes, 4.2b2; the Intrepid packages available from the kubuntu-experimental ppa.

I have a video of how the garbage disappears when I click the desktop, but it ended up at ~3.8mb (Vorbis) and the bugtracker doesn't seem to accept attachments larger than one megabyte. Perhaps I could host it elsewhere.

Video of the desktop garbage: http://www.sendspace.com/file/voy8r5

Ahh, I don't see them on base 8.10 with intel hardware :-)
Could you retest with a live CD or something of 8.10 with the new packages ?

I just want to mention that it seems that Compiz users are experiencing the same problem in Ubuntu Intrepid as well. For example please take a look at this bug report and the attached screenshot: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/313838

So I still think this is a downstream problem and we should not work around it.

*** Bug 179859 has been marked as a duplicate of this bug. ***

With a "fixed" (unpatched) xserver-xorg-core, I still experience identical garbage in Gwenview when cycling through images. To reproduce: compile a folder with images, open up one of them in said app, then hit spacebar rapidly.

(In reply to comment #77)
> With a "fixed" (unpatched) xserver-xorg-core, I still experience identical
> garbage in Gwenview when cycling through images. To reproduce: compile a folder
> with images, open up one of them in said app, then hit spacebar rapidly.
That seems to be a gwenview bug as it is reproducable with compositing turned off (try with alt+shift+f12). So this is a different bug and should be reported if it has not been reported yet.

I can confirm commen #77. Also I see garbage when switching to fullscreen in gwenview and dragon player (and dragon toolbar in fullscreen is totally full of garbage). This on an unpatched xserver

Hi, execperienced something similar on openSUSE 11.1 with the Intel driver, so I unknowingly filed a bugreport ( http://bugs.freedesktop.org/show_bug.cgi?id=19579 ) which MAY be the duplicate of this one, but I'm not sure, since the comments of this bug seem to describe distinct problems.

Some comments, like http://bugs.kde.org/show_bug.cgi?id=170462#c31 , http://bugs.kde.org/show_bug.cgi?id=170462#c37 and http://bugs.kde.org/show_bug.cgi?id=170462#c77 (as openSUSE doesn't use the patch mentioned in http://bugs.kde.org/show_bug.cgi?id=170462#c44) and even the original problem description seems to describe my problem, but others, like http://bugs.kde.org/show_bug.cgi?id=170462#c6 , http://bugs.kde.org/show_bug.cgi?id=170462#c7 NOT.

There are at least two bugreports regarding this topic on openSUSE's bugzilla:
https://bugzilla.novell.com/show_bug.cgi?id=464512
https://bugzilla.novell.com/show_bug.cgi?id=444373

And they have the following features in common:
-Seem to occur with the intel driver
-Unaffected by compositing
-Switching to XAA from EXA eliminates the problem!!!
-Easy to reproduce by gwenview and KDE login/logout
-Don't seem to be related to the patch mentioned in https://bugzilla.novell.com/show_bug.cgi?id=44

In my bugreport there is a screenshot and a video depicting the problem.

(In reply to comment #79)
> I can confirm commen #77. Also I see garbage when switching to fullscreen in
> gwenview and dragon player (and dragon toolbar in fullscreen is totally full of
> garbage). This on an unpatched xserver
> 
Your probelm with fullscreen apps looks to me like bug #177495 which is totally unrelated to the problem of video garbage.

I just wanted to say, that Ubuntu has removed the patch in their development branch leading to 9.04 (https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/254468/comments/41) and that the bug report has by now several duplicates concerning Compiz.

Cause of these facts I set the bug to DOWNSTREAM again. If anyone wants to workaround the problem (which I think is wrong) please reopen the bug.

This problem isn't Ubuntu specific.

(In reply to comment #82)
> This problem isn't Ubuntu specific.
> 
Well it is as you can read in comment #44. It's Ubuntu and Fedora specific. I have seen it myself, it's neither in for example debian nor in opensuse, which do not include the mentioned patch. And removing the mentioned patch resolves the problem as well as installing NVIDIA's 180.x driver which works around the mentioned patch. So it is very much distribution specific.

*** Bug 181606 has been marked as a duplicate of this bug. ***

(In reply to comment #81)
> (In reply to comment #79)
> > I can confirm commen #77. Also I see garbage when switching to fullscreen in
> > gwenview and dragon player (and dragon toolbar in fullscreen is totally full of
> > garbage). This on an unpatched xserver
> > 
> Your probelm with fullscreen apps looks to me like bug #177495 which is totally
> unrelated to the problem of video garbage.
> 
> I just wanted to say, that Ubuntu has removed the patch in their development
> branch leading to 9.04
> (https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/254468/comments/41)
> and that the bug report has by now several duplicates concerning Compiz.
> 
> Cause of these facts I set the bug to DOWNSTREAM again. If anyone wants to
> workaround the problem (which I think is wrong) please reopen the bug.

Actually, I think the 'right' solution would be to support the _NET_WM_SYNC_REQUEST protocol (mentioned in ajax' quote in comment #54) in KDE - or rather in Qt. Gtk+ supports it, which is why Gtk+ apps do not suffer from this problem under any compositor.
I don't think kwin compositing is the right component to assign to, but it's still something that could be done without being a workaround. Thus I suggest reopening the bug and/or reporting it to Nokia for fixing it in Qt.

There is a task for this in the Qt bug tracker: http://www.qtsoftware.com/developer/task-tracker/index_html?id=220550&method=entry

*** Bug 183684 has been marked as a duplicate of this bug. ***

Just as a datapoint to the Xorg maintainers reading this:

Since the patch has been applied to Ubuntu's upstream Xorg, compositing has slowed down for me to a degree that I'm now running without it.

For example, it takes well beyond one second to get the yakuake window up with compo on, while before the Ubuntu Xorg packages were updated, it would be almost instantaneously. It's absolutely swift with compositing off.

I'd much rather have the momentary garbage on the screen, that was only a visual distraction but didn't actually render the system less usable.

Hardware is ATI x1300, symptoms happen with the last couple of fglrx drivers and the free radeon driver in Intrepid.

I wonder if I should file a new bug, relating to this or maybe even reopen this one.

It wasn't 'only a visual distraction', it also appears to lead to security problems where elements of the screen were shown in the screensaver lock/unlock.
You should file a new bug, I think.

Hi,


In the Meantime, Is there any workaround for this bug ... It is Awful !! 
I cannot use my laptop with my customers.

Regards
vouchy

(In reply to comment #90)
> In the Meantime, Is there any workaround for this bug ... It is Awful !! 
It depends on your distribution. Ubuntu dropped the causing patch for the development release and there are unpatched packages in the ppa containing KDE 4.2. So Kubuntu users should not experience this behaviour any more.

I don't know how it looks like on Fedora.
> I cannot use my laptop with my customers.
That's sad

Hi,

Could you please help me to find a process to warkaround it with Fedora?

Rgs
vouchy

Hi 

Will There be a a warkaround/fix made for kde 4.2.1??is this fix already available in kde repos?

Rgs
vouchy

vouchy, my take (from a fedora pov) is that this is primarily an issue for qt/kde to address, by adding support for the sync protocol (see comment #85).  The only real short-term workaround is to disable the performance patch, which ajax (the fedora X maintainer) isn't likely to do, since it has side-effects (like comment #88).

@Rex Dieter: would it be possible for Fedora to at least provide packages without the patch in question? The way Kubuntu solved it is IMHO a good solution. Providing packages with the patch by default for Compiz users and packages without the patch for KDE 4.2 users.

That way users can choose what fits them more. I like many others do not have performance problems without the patch, so for me removing it is the right choice.

Indeed.
It's worth noting that even with the dropped patch I still get occasional corruption in Gwenview for instance, it's just no where near as bad or reproducible.

Everyone should pile onto the URL in #86 and we'll get it fixed correctly, imho. Hacking the X server is just a workaround, really, I think.

(Intel GM965, Kubuntu 8.10 w/KDE 4.2 from experimental w/their unpatched X server)

(In reply to comment #96)
> It's worth noting that even with the dropped patch I still get occasional
> corruption in Gwenview for instance, it's just no where near as bad or
> reproducible.
As already said in comment #78 gwenviews repainting issue has nothing to do with this behaviour as it is reproducable with and without compositing turned on and with and without the mentioned patch.
> 
> Everyone should pile onto the URL in #86 and we'll get it fixed correctly,
> imho. Hacking the X server is just a workaround, really, I think.
Which would be the earliest Qt 4.6. Quite some time.

Martin, I said "Gwenview for instance" because it also occurs in things like Kontact (KMail's message body view), and it happened once to the whole desktop (though never again).

Hi,


Is there a way to push for this bug fixing at qt level because the task tracker shows that bug is in pending state... Nobody cares for it!:=(

Please advise.
Rgs
vouchy

It is not that we don't care. You can see that since the bug was reported to affect KDE, it goes from priority 3 to 2.

A prototype have been made to implement the _NET_WM_SYNC_REQUEST protocol but it did not solve completely the problem of rendering.

Created attachment 31390 [details]
NET_WM_SYNC implementation

I've made a quick-and-dirty implementation of the _NET_WM_SYNC_REQUEST protocol, would be very helpful if someone can test if it solves the initial window painting issue before it is applied to Qt.

Hi,

I will test it.
But What version of qt are you using??
I am using 4.4.3 and patch is not for this version.

Rgs
vouchy

*** Bug 186213 has been marked as a duplicate of this bug. ***

for all who where looking for a screenshot, here you've got it:

http://gonetil.wordpress.com/2009/03/05/pantallas-feas-en-kde-4/

Thanks guys for everything!

Hi,

Did anyone test the patch #101 ?
Could we hope that it could be fixed at kde level??
or wait for QT ??

Regards
vouchy

Seems to be solved totally by KDE 4.2.1 (at leas on my 64bit openSUSE 11.1).

Bug 183684 (duplicate?) isn't solved with KDE 4.2.1 on debian.

Hi,

on FC10 64bits KDE 4.2.1 Issue is still there!!

Rgs
Vouchy

Confusion: even with the patch disabled, the corruption returns after installing a 2.6.29 kernel. I really can't see *why*, but it certainly does. This is on a Jaunty machine running kernel packages from: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.29

I fetched the (jaunty) xserver-xorg-core source to make sure the patch didn't get snuck back in by packagers, and it's properly disabled in ./debian/patches/series. Rebooting onto 2.6.28(-11), the garbage disappears once more. There's also some other minor garbage on .29, such as at the logout screen.

Does that make sense to anyone? Unrelated issue?

I can confirm the "new" garbage with kernel 2.6.29 on intel hardware. :( 
Patch disabled and no problems under 2.6.28.
SIGH!!!!!!!!!!!

FYI:

The situation became even worse here (intel graphics) after the latest upgrades (either X.org and/or kernel) in Intrepid.

I now have:
   xserver-xorg-core 2:1.5.2-2ubuntu3.1
   /boot/vmlinuz-2.6.27-13-generic

Now the same garbage appears:
1) Somewhat more often than previously
2) Instead of appearing in new windows that open, it appears when moving windows, in the areas that were uncovered by the move.  Uncovered garbage areas include existing windows and the desktop itself.

To reproduce simply grab a window by clicking on the title bar and drag it around.  To make the garbage disappear, click on it with the mouse (which seems to cause a refresh of the underlying window or area)

Graphics hardware is:
(--) PCI:*(0@0:2:0) Intel Corporation 82G33/G31 Express Integrated Graphics Controller rev 2, Mem @ 0xfdf00000/0, 0xd0000000/0, 0xfdd00000/0, I/O @ 0x0000ff00/0

Will be happy to add more details (please ask).

In response to comment #109 and #110: if the new kernel has a problem this looks like a regression in the kernel. But I think the mainline kernel does not contain the same Ubuntu patches as the official kernel and by that it's possible that it does not work with Ubuntu's X-Server. It's the task of the distributions to adjust their software in a way that they work well together.

In response to comment #111: please note that the issue is not and will never be fixed in the Intrepid release cycle. If it's an issue for you consider upgrading to Jaunty - tomorrow is the beta release.

*** Bug 188077 has been marked as a duplicate of this bug. ***

this sucks! okay i've tryed both ways it didn't work i still have the garbage ...i 've read every thing and are you sure that it is maybi solved in the new relase? i'm useing kubuntu 8.10 is upgrading to 9.4 make me loose my applications installed 
i am a newbi at linux started 4 days ago :) but have done so much to loose it all again...

To all Ubuntu Intrepid users experiencing the video garbage again:
"The xserver packages in the kubuntu-experimental PPA were superseded by a bugfix update in intrepid-updates with a higher version. The kubuntu-experimental packages will need to be updated with that fix." (see: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/254468/comments/67)

sorry can you explain...?
 i have a kubuntu 8.10 and i have updated to kde enviroment 4.2 ...and still have the problem ...
now you said that the kubuntu experimental packages will need to be updated .....again sorry i'm very very new and trying to learn fast so how do i update ... :) thanks

Firstlaw: https://launchpad.net/~kubuntu-experimental/+archive/ppa 
You can add the URL as a repository in Synaptic (for instance), update xorg and then remove the repository.
If you are very new, you might want to hold off, or try the Kubuntu 9.04 beta instead.

yeah i upgraded to 9.4 its great no problems :)

Seems fixed here on my intel driver using hardware with the 9.4 beta.

Upgraded to Kubuntu 9.04 Beta - no problems whatsoever (not even in the systray anymore).

NVIDIA Driver Version: 180.37
X Server Version: 1.6.0

Scratch that, it's not fixed - there is now other random corruption, as listed in the Kubuntu 9.04 beta release notes.

I can also confirm that it is not fixed for me in Kubuntu 9.04 beta and still the problem remains. The screen corruption occurs and traces of other applications are left in some applications, mostly Kontact/KMail.

X server version: 1.6.0
Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

Could you please re-open this bug?

The NET_WM_SYNC protocol has been implemented in Qt master (i.e. 4.6):
http://qt.gitorious.org/qt/qt/commit/2312b121131774a84d01854b3e47d3d2a035a6a1

And the related blog post in the Qt Labs Blog: http://labs.trolltech.com/blogs/2009/06/10/smooth-and-solid-resizing-on-x11/
(btw, notice how smooth window resize is in compiz, I wish it'd be the same in kwin)

I can confirm that this bug is not fixed with a GMA945 on 9.04. Running KDE 4.2.4.