Bug 155214

Created attachment 22885 [details]
Line under window decoration

Line under window decoration

Created attachment 22886 [details]
Mouse artifact example

Mouse artifact example

I have the exact same problem. And with transparency disabled, I have black horizontal lines as a continuation of bottom and top of windows.

I am using the kubuntu packages on hardy, but I had the same issue compiling from svn. I have a rv380 chip (X600) and using r300.

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

I cannot reproduce. What gfx driver, does the problem remain if you try a different version of it?

I am using the ati driver 6.7.197 which is the version provided by hardy. Should I compile from svn the ati driver to see if it helps ?


Feel free to askfor any info or debug output, I'll be glad to help tacking this problem.

I have a radeon mobility x600 (using the r300 and ati driver). I have kubuntu hardy and didn't touch the xorg.conf file. I can confirm the two screenshots above. The decorations and shadows do not paint correctly and there are two horizontal black lines (they attatch to the top and bottom of windows) from edge to edge of the screen and that move with the windows. This effect seems to be fairly reduced if I zoom out the desktop and move the window to a white area.

Created attachment 23455 [details]
Snapshot showing the mentioned artifacts.

Look at the bottom of the konqueror window and at the window decoration borders
and corners.

Same problem here with an r300 and the radeon driver.

Playing a bit with the settings I found that the problem is oxigen related. No one other decoration shows these artifacts. Also they only apear when using opengl. They are not present when using Xrender.

Problem persists in kde 4.0.3 kubuntu packages and in trunk.

I can confirm this with any of the open r300 drivers shipped with Debian in unstable and experimental since KDE 4 was launched, and every version of KDE shipped by Debian (4.0.0, 4.0.1, and 4.0.68+svn794641).

Would forwarding this to the r300 developers be a good idea?

I think it might be a good idea to report that to the r300 developers.I have no idea where the r300 bugs are hosted though...

Actually, I pinged their mailing lists...

ATI Driver:
http://lists.x.org/archives/xorg-driver-ati/2008-April/005120.html

Suggested I try Mesa:

http://marc.info/?l=mesa3d-dev&m=120912773010214&w=2

I never did file a bug with MESA... I was hoping the message would stir some interest.

I opened bug 16123 on the Mesa bit of the Freedesktop bugzilla. It gives a very brief description and refers back to here.

https://bugs.freedesktop.org/show_bug.cgi?id=16123

The comment on the Mesa bugzilla is:

"Probably driver specific.

Again, it would be good to get some input from KDE developers as to what kwin
does differently from compiz. It could be quite tedious to track this down for
somebody unfamiliar with the kwin code."

https://bugs.freedesktop.org/show_bug.cgi?id=16123

So this is down to things well beyond my depth :)

I still have the issue with the packages of KDE4.1 RC1 from intrepid.

Can we hope to see this issue investigated for 4.1 ? Is there a way to know in which component, kwin, mesa or r300 lies the issue ?

I rember to have seen this issue on my laptop (ati card). I will try to reproduce both with fglrx and the free driver. Personally I think it is a problem of the free driver as I don't remember to have seen this bug since I switched to the proprietary driver.

It looks like upstream got this:

http://bugs.freedesktop.org/show_bug.cgi?id=16123

The first person to build this or get new packages should probably report back here.

I can confirm this being fixed with the current git version of mesa. Checked with kwin-4.1-rc1 on Gentoo.

[R300 DRI developer speaking]

Unfortunately, that commit in Mesa Git breaks some of our regression tests, so we'll have to investigate this further. The code in our driver does look a little fishy, but the current fix doesn't appear to be the final wisdom either.

Okay, so it turns out we had a rather embarassing bug in cliprect handling that went unnoticed for many years. I *think* I fixed it properly in http://cgit.freedesktop.org/mesa/drm/commit/?id=90b90c65dc78648ddded5eff7628749182c73295
At least, our regression tests are passing again, and other odd effects related to cliprect bugs are gone.

The weird thing is, my commit reverts Michel's earlier fix in some sense, though not quite. Here are the technical details:

Michel's patch to Mesa fixes our implementation of glScissor, where we had (incorrectly) behaved as if software cliprects had inclusive bottom-right corners. In doing so, it essentially did a +1 to x2/y2 coordinates.

My patch fixes the DRM, which also incorrectly behaved as if software cliprects had inclusive bottom-right corners. In doing so, it essentially does a -1 to x2/y2 coordinates.

So the end result is that the coordinates with scissors enabled are exactly the same as before. *However*, since the behaviour now is different with scissors *disabled*, it's quite possible that the KWin artifact problem is fixed. It all depends on whether the artifact was due to incorrect scissors or due to other corruption caused by incorrect cliprects.

Please, somebody retest with latest DRM (I don't have a proper KDE setup).

Being the idiot who introduced the bug in the first place, so many years ago, I apologize for the inconvenience.

After updating to the latest mesa/drm and mesa/mesa versions I see no rendering artifacts with kwin-4.1. Many thanks!

Closing then, not a bug in KDE.