Version: Version 4.1.71 (KDE 4.1.71 (KDE 4.2 >= 20081023)) (using Devel) Compiler: gcc version 4.3.2 OS: Linux Installed from: Compiled sources When the new dolphin tooltip previews images and the tooltip preview goes over the plasma panel, it corrupts it leaving a imprint and a chunk of the panel missing. Screenshot http://img217.imageshack.us/my.php?image=plasmapaneltipcorruptioay3.png Using Xserver 1.5, opensourse nv driver.
eh, an old graphics drivers bug that persists with several drivers when composite is off. i fear we can't do much on that one
yes, that is. :(
*** Bug 182616 has been marked as a duplicate of this bug. ***
*** Bug 182314 has been marked as a duplicate of this bug. ***
Is bug 192053 also related to this? Thanks
*** Bug 177959 has been marked as a duplicate of this bug. ***
*** Bug 192053 has been marked as a duplicate of this bug. ***
If it really was a bug in graphics drivers then they must have found a workaround because in 4.3-beta I can't reproduce it no matter how hard I try (and it's easy in 4.2).
"Upstream" means "the fix needs to happen upstream, it doesn't belong on our bug tracker."
There is a workaround for this bug by adding the following line to your xorg.conf. Section "Extensions" Option "Composite" "Disable" EndSection If you don't use Desktop Effects, this will stop the bug above.
Maybe I was not clear enough: The bug was said to belong upstream, to the graphics drivers. I always understood and accepted this resolution. But now I tried KDE-4.3-beta1 and with the same graphics drivers the bug is fixed. So *if* it certainly was (is?) a bug belonging to graphics drivers, then the KDE developers have managed to workaround it somehow. Because it is fixed now. And the fix happened in KDE code :) Big thanks!
No. There is no evidence to suggest it's a "graphics driver" bug but more that it's a Xorg bug. It has 'not' been fixed and I can reproduce it every time in 4.3. I was told of the above workaround which 'does' work. It's not a KDE issue it seems so I just though I'd update with that workaround for any duplicates.
*** Bug 194029 has been marked as a duplicate of this bug. ***
*** Bug 184314 has been marked as a duplicate of this bug. ***
*** Bug 197602 has been marked as a duplicate of this bug. ***
*** Bug 198481 has been marked as a duplicate of this bug. ***
I experience these problems too with both the intel-driver as well as vesa+shadowfb (which is pure software rendering), running fedora rawhide (xorg-1.7-pre) on kde-4.3-beta2. Shouldn't this be more investigated and worked on, keeping in mind how frequent and annoying this bug is?
by the way I am tired of KDE's bug mentality. Did at least somebody take care wether these problems have been reported upstream before closing this bug? All in all it seems like a big bug-count hunt down, where the only goal is to get the official bug count down, to make KDE way better on paper. KDE4 is still buggy, and sometimes quite slow. It eats more memory than KDE-3.5, isn't as responsive or as stable. What you guys ship as stable enters beta at Microsoft. I would really appriciate 4.4 beeing a no-new feature release dedicated to tuning and bug-fixing.
(In reply to comment #17) > I experience these problems too with both the intel-driver as well as > vesa+shadowfb (which is pure software rendering), running fedora rawhide > (xorg-1.7-pre) on kde-4.3-beta2. > > Shouldn't this be more investigated and worked on, keeping in mind how frequent > and annoying this bug is? It's a Xorg bug, nothing KDE can do about it. There is such things as lower stack bugs you know, so don't make out KDE4 has all the bugs.
I was angry because the report was simply closed with the comment "not our buissness", it was not even made sure it has been reported upstream (I did that yesterday). > There is such things as lower > stack bugs you know, so don't make out KDE4 has all the bugs. For the end user it doesn't matter, it will just see a lousy desktop experience.
It might not be KDE's bug, but perhaps KDE can code a workaround. Also, what is the specific Xorg bug number? Perhaps those of us affected by this can vote for it. Or maybe Xorg has an experimental patch we can apply ourselves.
https://bugs.freedesktop.org/show_bug.cgi?id=22566 however xorg usually is even worse fixing bugs ;)
(In reply to comment #21) > It might not be KDE's bug, but perhaps KDE can code a workaround. Also, what is > the specific Xorg bug number? Perhaps those of us affected by this can vote for > it. Or maybe Xorg has an experimental patch we can apply ourselves. What Aaron told me is that he hammed on to Xorg devs about out it and they refused to admit it was a xorg bug. So please don't make assumptions because the same assumptions where said about KDE4 being slow with the nvidia driver, guess what happened? The 180.xx series pretty much fixed it. OpenGL and plasma crashes Nvidia fixed as well, so don't make such assumptions.
@David Johnson: the only work around is to not use an argb visual in plasma (or konsole, or any other app running on x.org). that means: no translucency in the panels or popup windows, no sliding animations that don't grind your CPU to a halt (though we'll be working around that last one by pushing it into the kwin desktop effects in 4.4), etc.. this is a bug that we can't work around without giving up a whole set of features that work perfectly for some people and which _ought_ to work. the only way x.org people will ever fix this kind of thing is if applications actually use it and users file bugs against x.org about it. @Sean Wilson: "What Aaron told me is that he hammed on to Xorg devs about out it and they refused to admit it was a xorg bug." at first there was denial about where the bug existed, but after i demo'd it to several of the x.org devs in person (mostly in airport lounges, oddly enough) they copped to the problem. now we just need a fix. :/
I've already posted a workaround, see comment #10 https://bugs.kde.org/show_bug.cgi?id=173686#c10 Is it really that hard?
Yes, you can neuter your x.org via xorg.conf. I don't think that's what most users want, of course, but it does work as long as you don't need/want any compositing. :) Ah, you can also probably start KDE with the KDE_SKIP_ARGB_VISUALS env var set to 1, and that will achieve something similar without killing compositing completely. You'll get some rather ugly results if desktop effects are enabled though. :)
Do the popups really use ARGB visuals even without compositing? I always thought that it uses the shape extension in this case?
> Do the popups really use ARGB visuals even without compositing? it's not the popups, it's the whole application that does. the visual needs to be set up at application start, which means we have to decide whether to support compositing or not at log in for plasma. while it might be acceptable to restart konsole (though certainly less than good), it's unacceptable for plasma because we don't know whether the compositing manager will appear before or after plasma starts, nor do we know if the user will turn on effects later.
I don't entirely understand the technicalities above, but I just wanted to point out regarding the workaround interfering with compositing - from comment #1, as well as my own experience, it seems this bug occurs only when compositing is turned off in the first place. With desktop effects enabled, I can't reproduce the bug (while with effects enabled, I can reproduce it consistently, as described in https://bugs.kde.org/show_bug.cgi?id=192053).
*** Bug 188806 has been marked as a duplicate of this bug. ***
Couldn't a workaround be applied to the code which displays the tooltips? Regular qt tooltips don't trigger the bug. As the bug occurs at many people, but in most cases only with compositing disabled (that is, little eye-candy anyway), in the worst case you could fall back to reguar Qt tooltips when compositing is disabled.
Grósz: regular qt apps don't use argb visuals, that's why the problem doesn't occur. argb visuals have to be used anyways even if composite is disabled if we want to ever have the possibility to do transparent windows, and the problem would be present even with regular tooltips
Personally, I'd happily settle for being able to disable the tooltips, as I don't need them anyway so for me they're a double nuisance - they get in the way when the pop out and mess up my display when they go away.
Tooltips can be easily disabled in Dolphin's settings (isn't it the default anyway?). Another workaround can be to enable compositing but disable most of the effects. I do this and enjoy better plasma themes without any annoying effects (like minimizing windows, shadows, transparent windows when moving them around, etc...).
Well, actually I meant this comment about Plasma tooltips which cause similar (but more frequently happening) artifacts, reported in a separate bug report which was marked as a duplicate of this. Only Plasma tooltips cause that bug; e. g. systrey icons like KMix's with a plasma tooltip too but not Kopete's which has a regular tooltip (maybe it's not standard Qt but a normal KDE application tooltip and not Plasma's). If I understand correctly, ARGB is needed for transparent panels and the like, which are available only with compositing anyway, isn't it? If that's the case, couldn't it be disabled if compositing is disabled? #34: on slower systems without 3D acceleration compositing with XRender slows down the system even if few effects are used.
*** Bug 225030 has been marked as a duplicate of this bug. ***
S. instead of working with Xorg on a fix, this has been marked as "not our problem". Two friends of mine also use KDE-4.3/4.4 (one tech guy, the other one is "only" a user), and both (including me) are annoyed by this bug. How do you justify having "holes" appearing somewhere in your windows, when demonstrating a KDE based linux system, just because somewhere a popup shows up.
@Grósz Dániel: "couldn't it be disabled if compositing is disabled?" see: http://userbase.kde.org/Plasma/4.2#Disabling_ARGB_visuals the visual must be set at app start otherwise it can't switch between compositing and non-compositing modes. but you can control it manually using the above. @ Clemens Eisserer: "S. instead of working with Xorg on a fix, this has been marked as "not our problem"." i have demonstrated the problem to x.org devs several times. it is up to them to fix it. just as a flaw in a Linux kernel driver is unlikely to be fixed by me even if we can trigger it using something in plasma-desktop. if you would like to try fixing it, please do so. "How do you justify having "holes" appearing somewhere in your windows" we don't justify it. it's a bug, and we openly state that. but it is a bug in x.org, not in kde's code. filing bugs here on bugs.kde.org and complaining on bugs.kde.org is not going to get anything fixed in x.org. go to x.org's bug tracker and share your annoyance with people there.
*** Bug 229273 has been marked as a duplicate of this bug. ***
Just to be sure this problem is not related to the small bug I see when the first tooltip is shown after "an idle time" (show tooltips, then do other things for about 30 seconds and get the mouse over the panel to show tooltips again): the position of this first tooltip is not the right one (also is when the holes are created for me). The following ones are in the right position and do not create holes. I was about to check this, but I'm now full of job and I can not do it.
*** Bug 243038 has been marked as a duplicate of this bug. ***
so it's upstream. i'm only a simple user. what/which driver to be exact? who responsible to fix it? where to report this bug? or is it reported already? will it ever be fixed (upstream)??
As far as I can tell its an XOrg bug, as it looks for now nobody will ever fix it :/
If somebody is interested in having it fixed, please report it to the X.Org developers and post the link to that bugtracker entry here for reference.
I filed a bug report there about a year ago: https://bugs.freedesktop.org/show_bug.cgi?id=22566
*** Bug 264322 has been marked as a duplicate of this bug. ***
I tried to use the KDE_SKIP_ARGB_VISUALS=1 workaround, but it does not work. I still have these problems. I wrote in in ~/.profile, and did relogin, I tried to directly restart plasma-desktop with pkill plasma-desktop KDE_SKIP_ARGB_VISUALS=1 plasma-desktop and also KDE_SKIP_ARGB_VISUALS=1 dolphin Has really anyone succeeded in fixing this by that workaround?
This is clearly a Xorg bug, I was able to write a xlib-only testcas (as I was asked for), but then nothing happend. If you want this bug fixed, please make some polite noise at: https://bugs.freedesktop.org/show_bug.cgi?id=22566
(In reply to comment #48) > If you want this bug fixed, please make some polite noise at: > https://bugs.freedesktop.org/show_bug.cgi?id=22566 I don’t see any possibility to “vote”?
*** Bug 267641 has been marked as a duplicate of this bug. ***
This bug has been fixed by xorg-developers, after I created a stand-alone xlib-only testcase and filed a bug. In this case it would have been helpful if KDE developers would interact more with upstream - instead of just closing reports. After all, for the user it doesn't make a difference who's "faulT" it is - it simply doesn't work for him/her. So instead of pointing fingers, next time simply use the time to create a bug-report at xorg's bugzilla ;)
yeah!, thank you Clemens for your work and patience!
*** Bug 264957 has been marked as a duplicate of this bug. ***