|Summary:||R700, DRI2, KMS: minor mouse pointer corruption|
|Product:||xorg||Reporter:||Josh Saddler <nightmorph>|
|Component:||Driver/Radeon||Assignee:||xf86-video-ati maintainers <xorg-driver-ati>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|Priority:||medium||CC:||aklhfex, chewi, remi|
|i915 platform:||i915 features:|
Description Josh Saddler 2009-10-03 02:36:34 UTC
So the new KMS support in .32_rc2 and git driver stack for my R700 card works great! Except that there's some minor mouse pointer corruption. The corruption is not present when using the mouse in Firefox, or when the pointer changes to anything other than the default "arrow" pointer whether in Firefox or just in my Xfce desktop or in another application. The corruption manifests itself as a series of three small dots hovering over the default "arrow" pointer. It appears on xfdesktop, xfwm4, and within all other opened applications in my Xfce environment...except Firefox, curiously enough. I'm using the very common "Vanilla DMZ Xcursors" theme from: http://jimmac.musichall.cz/themes.php?skin=7 This error did not appear with the old xorg-server 1.6.3.x, libdrm-2.4.13, video-ati-6.12.4, and mesa-7.5.1--the "stable" stack for Gentoo. -Hardware RadeonHD 4550 (lspci: ATI Technologies Inc Device 9540) x86_64 AMD Athlon(tm) Dual Core Processor 4450e AuthenticAMD GNU/Linux DVI LCD monitor -Software mesa master: EGIT_VERSION=be16acaafa2f28bb7d4551ed93d2e290c928006c libdrm master: EGIT_VERSION=04495eeec2f053be17a10cc82e646a1e23ed3830 xf86-video-ati master: EGIT_VERSION=cc45856a18dd3e6f7e44d9eb507b31419da70977 xorg-server: 1.6.4 kernel: 2.6.32-rc1-git3 dri2proto: 2.1 I'll attach Xorg.0.log, dmesg, xorg.conf, and screenshots. (An aside: thanks so very much for the amazing progress made in xf86-video-ati and the rest of the stack for R700 cards. I bought this card some months ago specifically because of the driver support that would one day roll around. Yes, just like in the XKCD strip: http://xkcd.com/644)
Comment 4 Josh Saddler 2009-10-03 02:39:39 UTC
Created attachment 30009 [details] 20091003-firefox-goodmouse.png The uncorrupted, good default mouse pointer in Firefox.
Comment 5 Josh Saddler 2009-10-03 02:40:21 UTC
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.
Comment 6 Josh Saddler 2009-10-03 02:42:41 UTC
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.)
Comment 7 Josh Saddler 2009-10-03 02:45:36 UTC
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!
Comment 8 Josh Saddler 2009-10-03 03:08:44 UTC
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.
Comment 9 Alex Deucher 2009-10-03 07:51:35 UTC
Does disabling kms fix the it? How about: Option "EXANoDownloadFromScreen" in the device section of your config?
Comment 10 Josh Saddler 2009-10-03 19:23:46 UTC
(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?)
Comment 11 James Le Cuirot 2009-10-10 08:43:21 UTC
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.
Comment 12 Alex Deucher 2009-10-12 08:38:09 UTC
This might be a duplicate of bug 24430. Does it still happen with the latest bits from drm-next?
Comment 13 Josh Saddler 2009-10-12 11:36:31 UTC
(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?
Comment 14 James Le Cuirot 2009-10-13 15:53:24 UTC
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.
Comment 15 Josh Saddler 2009-10-13 16:13:01 UTC
(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.
Comment 16 Josh Saddler 2009-11-15 18:12:06 UTC
(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.
Comment 17 Josh Saddler 2009-12-16 23:09:45 UTC
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. :)