AMD Catalyst 11.5 Linux Driver Released

[pflynn]

Ah, that issue of a screwy cursor still around is it? I've had that since....11.2 I think it was. I've switched back to 1 monitor these days (of all things, new video card, fan spins quieter with one monitor), but the fix I had was to use software cursors (manually edit xorg.conf for that).
Section "Device"
...
Option "SWCursor" "true"
EndSection

I did that for both monitors, but you should really only need it for the external (or secondary) one.

OMG!
This bug began to trouble me since my upgrade from Slackware 13.1 to 13.37. But it is even worse when you have three monitors. I filled out a bug report on the AMD Unofficial Linux Bugzilla (Bug 117 - http://ati.cchtml.com/show_bug.cgi?id=117 ). I was looking for a definitive solution or even an workarround on this bug, but I had no luck...until now. Your suggestion on using software cursors solved my problem. I owe you!

[Ex-Cyber]

Is it wrong that the concept of hardware cursor support for a modern GPU amuses me a bit? I assume it's nice for not causing repaint events every time the user's wrist twitches, but it reminds me of how the Atari 2600 graphics chip has a dedicated set of registers for "the ball" (not a dedicated color register, though; you think flip-flops grow on trees or something?).

[mirv]

This is amazing, I've had lock up problems since I bought this laptop and now with software cursor it is perfect, I've abused it anyway I can and it is rock solid thus far.
I'm starting to get my confidence back and starting to trust the thing, it's plain weird that something so "simple" as a mouse cursor is getting in ati's way.

Glad I could help with that. I never had problems with stability, just that a corrupted cursor was really annoying! Obviously though, different systems will be affected differently - sucks to be the developer trying to track that bug down.

[pflynn]

Hi mirv,

How did you find this solution? Do you have any more information that you can share so we can go ahead and find a final solution?

[mirv]

Hi mirv,

How did you find this solution? Do you have any more information that you can share so we can go ahead and find a final solution?

I can't remember exactly where I found it - but I'll give what info I can. The same bug (well, similar) happened quite a while ago (hmm....maybe 1.5 years or more) but was fixed. At the time, a few people switched across to software cursors to see if it would make a difference (think it was on the gentoo forums I first read it), so I remembered it from then. Of course, back then, it happened on all monitors, now it's only the secondary output.
I don't know if the bug exists in only recent xorg-server versions - I came across it when updating a few things at once, including going from xorg-server 1.9 to 1.10, but I did run into the following:
* Happens on secondary monitor (dual-head mode). Switching which monitor is primary simply switches which monitor cursor corruption occurs on (so I guess it's not tied into the physical port at all).
* I used e16, but recently switched to e17. e17's normal cursor is fine, but system default is affected. Whatever e17 does to the cursor isn't affected. Still annoying as "inside" an application, the default system (i.e not e17) cursor is used. e16 always used the default system cursor, so it was always corrupted.
* Obviously software cursors work, but then software cursors aren't overlayed on opengl windows properly. It will flicker a little whenever moved.
* For me, the corruption looked to have some correlation with the screen coordinates. It wasn't entirely random. Moving the cursor over a particular application (pidgin, for example) would result in the same pattern when moved over the same area. Move to a different area, it might change, move back, it'll revert to what it was before.
* Monitors were of different size and resolution, same refresh rate.

I can hook up the 2nd monitor again at any time, so I can still test this issue in the future. I'm just a quiet computer nut (see previous post about why I switched to one monitor).
Like I said, I went from xorg-server 1.9 to 1.10, and updated fglrx at the same time, so I've always been curious if it's that combination that's the problem. I might have time to check it on Sunday, but that's not definite. Otherwise, that's about all the info I can give on it!
Running Gentoo (64bit), PhenomIIX6, and noticed the problem on a radeon3650, and radeon6950, on e16 and e17. I don't use gnome or kde, or anything else actually, so no idea about those. Kernel version I can't remember (which is sad of me)...2.6.34 I think (not at my own computer right now, but I can check it later).

[pflynn]

Hmmm...nice!

I think this bug is related to the XOrg version, only. This is because the bug appeared to me after my upgrade from Slackware 13.1 to 13.37. Before 13.37, I was running the same kernel (2.6.37) and Catalyst version (11.4), and I had no issues. I also tryed a rollback to Catalyst 11.3 in 13.37 (that was pretty functional in 13.1), but the bug was there also. Thank you again for all the information!

[PsynoKhi0]

The SWCursor quirk on dual displays also applies to openchrome (hmm that feels like déjà vu)

Catalyst 11.5 working great here. Solved the issue I had in Shadowgrounds with 11.4

Performance in Ryzom is still abysmal though the devs seem not to do any work on ATI hardware. Shame really. Oh well, no money from me till it's solved.

[Qaridarium]

Ah, that issue of a screwy cursor still around is it? I've had that since....11.2 I think it was. I've switched back to 1 monitor these days (of all things, new video card, fan spins quieter with one monitor), but the fix I had was to use software cursors (manually edit xorg.conf for that).
Section "Device"
...
Option "SWCursor" "true"
EndSection

I did that for both monitors, but you should really only need it for the external (or secondary) one.

this bugfix helps me to fix another bug.... a frend chance from 32bit kernel to 32bit-PAE kernel and the mouse pointer turn into a black cube after this bugfix the mouse pointer is right again.

very strange.. thank you very much for your multi-fix-bugfix