Bug 24287

Created attachment 30006 [details]
dmesg

Created attachment 30007 [details]
Xorg.0.log

Created attachment 30008 [details]
xorg.conf

Created attachment 30009 [details]
20091003-firefox-goodmouse.png

The uncorrupted, good default mouse pointer in Firefox.

Created attachment 30010 [details]
20091003-xfdesktop-badmouse.png

This is the bad, slightly corrupted pointer when hovering over my desktop in Xfce. Notice the three dots that are above and not-quite-centered.

Created attachment 30011 [details]
20091003-xfwm4-badmouse.png

And here's the corrupted pointer again. This is what it looks like when hovering over xfwm4 windows and within the main window of every other application in Xfce. only Firefox doesn't have a corrupted pointer.

As I mentioned earlier, though, there are no dots nor any other corruption present in any of the alternative pointers I've seen so far. (Resize X/Y, stopwatch, stopwatch+pointer, text cursor, etc.)

Uh . . . and I just noticed that the screenshot-taking app *removed* the corruption from all pointers. Like magic. So I'm going to have to figure out a way to make sure this gets in there. Sorry for the bad shots!

Created attachment 30012 [details]
badmouse1.JPG

Okay, this is a cropped shot taken with a digital camera. It's much crisper in real life, obviously. I suppose I could simulate it with the GIMP in one of the other desktop pictures by just drawing three white periods, just a couple pixels across, over the mouse pointer.

I asked my fellow Gentoo developers why the corrupted pointer isn't in the screenies, and they seem to think that it's because the pointer is rendered by some other chip than the GPU and then composited to the screen.

Whatever the cause, I apologise for the bad shots earlier. HTH.

Does disabling kms fix the it?
How about:
Option "EXANoDownloadFromScreen"
in the device section of your config?

(In reply to comment #9)
> Does disabling kms fix the it?
> How about:
> Option "EXANoDownloadFromScreen"
> in the device section of your config?

Thanks for responding so quickly, Alex.

Passing "radeon.modeset=0" to the kernel does remove the corruption.

Setting "EXANoDownloadFromScreen" "true" in xorg.conf ALSO fixes the corruption.

I tried both fixes independently, rebooting each time. They both work, though without KMS obviously my boots are uglier.

I haven't tried disabling KMS *and* the EXA option at the same time -- you want me to try it?

(Also, it may be my imagination, but enabling EXANoDownloadFromScreen feels like it's making my system a little slower. Like things are drawn slowly. I only feel like something's happening because I'm running off an SSD, which is making me sensitive to anything that's not an instant response. Or I could be crazy, and there's no actual difference. Does this option actually affect desktop performance?)

I experienced some pointer corruption (though it looked different) just now with a 4670 and KMS enabled. Enabling EXANoDownloadFromScreen seems to have done the trick.

This might be a duplicate of bug 24430.  Does it still happen with the latest bits from drm-next?

(In reply to comment #12)
> This might be a duplicate of bug 24430.  Does it still happen with the latest
> bits from drm-next?

I don't use the drm-next tree; I'm on git-sources-2.6.32_rc3-r3. I just read on Phoronix that _rc4 is out -- should I switch to it, disable the ExaNoDownloadFromSscreen setting, and report back? Do I need to switch over to drm-next and build the kernel from that repo?

Or should I just update my git checkout of the mesa/libdrm/video-ati masters and rebuild my drivers?

I am now running today's linux-next (20091013) and I know that this includes all the latest drm-next code. The problem appears to be fixed.

(In reply to comment #14)
> I am now running today's linux-next (20091013) and I know that this includes
> all the latest drm-next code. The problem appears to be fixed. 

Not for me, and this is my bug.

I notice that the screen corruption continues after launching OpenGL apps without using the LIBGL_ALWAYS_INDIRECT=1 environment variable. Normally I used this fallback hack to make sure that Nexuiz could launch.

While the latest git checkouts for mesa/libdrm/video-ati make it possible to play the game without that environment variable, the same kind of mouse pointer corruption appears in a line near the top of my screen, about 3/4 of the whole screen. Buncha small dots, though this time not attached to the pointer. They remain a bit below my taskbar until I restart my X session or drag a Firefox window across it to "erase" 'em.

I have moved to kernel 2.6.32_rc4-r1; this definitely made it possible to play Nexuiz at all, but the screen corruption is still intermittent. 
I'm still tryin' to diagnose what's going on.

(In reply to comment #15)

Still present even with kernel 2.6.32_rc7, and recent git checkouts of the driver stack (Nov. 14).

mesa: 57f40b18377f87c434f17d5670a13838d58065c9
libdrm: 83a35b68f45cebc70152e55ed3f99db485c9a7cd
xf86-video-ati: 0c4710c67a2fee2061fc3da43c9f908585693cfa

I disabled the EXANoDownloadFromScreen option just to see if the pointer corruption had gone away in the past month, but nope. It's still there.

This is now fixed as of kernel 2.6.32, and the following git versions:

libdrm: edc77dd291594e017ca0ee96a785412107ebff74
mesa: 3ff688ea299581e60caf5d6e1a464f68c717fe83
xf86-video-ati: 299d395bd3f294239dee58ab7d607d7d2c657f61

These checkouts are all from December 14. After removing the EXANoDownloadFromScreen option from xorg.conf and rebooting, there's no longer any corruption.

So I dunno what happened between then and now, but I like it. Good job, and thanks. :)