Bug 13405 - radeonhd: cursor: linebuffer problems.
Summary: radeonhd: cursor: linebuffer problems.
Status: CLOSED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/radeonhd (show other bugs)
Version: git
Hardware: x86 (IA32) All
: medium normal
Assignee: Luc Verhaegen
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 13468 13735 14499 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-27 06:12 UTC by Sebastian Brocks
Modified: 2009-05-11 21:20 UTC (History)
13 users (show)

See Also:
i915 platform:
i915 features:


Attachments
logfile (244.77 KB, text/plain)
2007-11-27 07:51 UTC, Sebastian Brocks
no flags Details
Xorg log with panel and external monitor (43.49 KB, text/plain)
2008-01-03 03:21 UTC, Adrian Davey
no flags Details
Working Xorg.0.log (32.55 KB, text/plain)
2008-01-11 13:15 UTC, Zeqadious
no flags Details
PANEL only Xorg log file - Works fine (206.42 KB, application/octet-stream)
2008-07-22 21:41 UTC, Praveen Kumar
no flags Details
DVI+VGA (PANEL closed) Xorg log file - Facing cursor issue (332.06 KB, application/octet-stream)
2008-07-22 21:43 UTC, Praveen Kumar
no flags Details
Workaround: leave HW cursor enabled for both CRTCs (747 bytes, patch)
2008-11-07 23:26 UTC, Yang Zhao
no flags Details | Splinter Review
Xord.0.log showing HWCursor complaint (174.68 KB, text/x-log)
2009-02-25 10:15 UTC, Alec Habig
no flags Details

Description Sebastian Brocks 2007-11-27 06:12:41 UTC
using randr, I get a flickering mousecursor in a few well-defined areas
of one of my screens.
There are 4 vertical "lines", about 20 pixes in width that go across the
screen from top to bottom. When I place the mouse cursor on top of these
"lines", I get a flickering mouse cursor.
The 4 lines are at about 235-255 pixels from the left edge of the
screen, at 490-510 pixels from the left edge, at at 940-960 pixels from
the left edge and at 1005-1025 pixels from the left edge.
On the other monitor, this does not happen.
The resolution the monitor on which it is happening is running is 1280x1024.
I'll attach a small video showing the flickering.
Comment 1 Sebastian Brocks 2007-11-27 06:16:27 UTC
Hm, the file is too large for bugzilla.
Find it here: http://www.deckmaker.mynetcologne.de/SNV30609.AVI
Comment 2 Matthias Hopf 2007-11-27 06:26:12 UTC
This looks like a memory controller issue. Did you happen to use fglrx before? That driver is known to mess with the MC.
Comment 3 Sebastian Brocks 2007-11-27 07:03:07 UTC
I did, but that's more than a month ago, and I'm not using it anymore.
Comment 4 Luc Verhaegen 2007-11-27 07:31:56 UTC
Have you done a powercycle since then?

Which hardware is this, which driver version is this, can you provide a log?
Comment 5 Sebastian Brocks 2007-11-27 07:50:33 UTC
I've shut-down and restarted my computer several times since then.
It's a Radeon X1900GT from Sapphire,
and I'm running current git.
Comment 6 Sebastian Brocks 2007-11-27 07:51:19 UTC
Created attachment 12742 [details]
logfile

Xorg.0.log
Comment 7 Luc Verhaegen 2007-12-11 08:13:57 UTC
*** Bug 13468 has been marked as a duplicate of this bug. ***
Comment 8 Luc Verhaegen 2007-12-19 13:06:25 UTC
*** Bug 13735 has been marked as a duplicate of this bug. ***
Comment 9 Adrian Davey 2008-01-03 03:11:59 UTC
Following on from the duplicated bug #13735, I have discovered that if I have an external monitor attached to the vga port, the laptop panel works correctly, correct resolution, no flickers on the laptop panel at all. I am adding the Xorg log from this invocation so that a comparison can be made to that of #13735 attachments.
Comment 10 Adrian Davey 2008-01-03 03:21:08 UTC
Created attachment 13478 [details]
Xorg log with panel and external monitor
Comment 11 @4u 2008-01-10 07:28:37 UTC
(In reply to comment #9)
> Following on from the duplicated bug #13735, I have discovered that if I have
> an external monitor attached to the vga port, the laptop panel works correctly,
> correct resolution, no flickers on the laptop panel at all. I am adding the
> Xorg log from this invocation so that a comparison can be made to that of
> #13735 attachments.
> 

I have an Thinkpad T60 here and it is exactly the other way around. If I do not add an external monitor, everything works fine. If I add a 1024x768er one the internal monitor starts to flicker in some small areas.

Please let me know if any log file or other data is needed.
Comment 12 Zeqadious 2008-01-11 13:15:32 UTC
Created attachment 13665 [details]
Working Xorg.0.log

No external monitors attached, just my Laptop Panel.
Comment 13 Zeqadious 2008-01-11 13:16:58 UTC
Latest commit:
RADEONHD: version 1.1.0, built from git branch master, commit 0f066c20

Seems to be working for me now.
Comment 14 Konstantin Svist 2008-02-14 14:09:02 UTC
*** Bug 14499 has been marked as a duplicate of this bug. ***
Comment 15 Konstantin Svist 2008-02-14 14:10:05 UTC
I have the same issue, with latest version (commit a9af866ae712a0048d374dc640e482d1f4ce8859)
Comment 16 Alec Habig 2008-02-14 14:17:44 UTC
Also confirm that it's still here, see the duplicate Bug 14999 for my info (sorry for the dupe).  Also a Thinkpad T60p, but the opposite of comment #11 - external monitor has the problem, internal is happy.
Comment 17 Matthias Hopf 2008-02-19 09:55:32 UTC
Excerpt from Bug 14499 by Konstantin, who found out some interesting details:

Cursor corruption appears when the cursor is on particular parts of the screen.
The corruption appears as blinking lines next to, or on top of the cursor.
These distortions don't change in patter if the cursor is moved strictly up and
down (same horizontal pixel), but change if the cursor is moved to left or
right, even by 1 pixel. The affected areas of the screen are columns ~10px wide
around every 255px (x % 255 == 0, but not x === 0).
The corruption seems to be limited to the cursor only - it doesn't stay around
when the cursor is moved away, and doesn't appear on screenshots.
Different cursors (arrow, text selection, etc) seem to be all affected by the
problem.
Comment 18 David Halik 2008-02-28 13:39:00 UTC
Same issue here with Fedora 8 and both a X1600XT and X1650
Comment 19 Sebastian Redl 2008-02-28 14:13:16 UTC
Same issue with an X1550, nearly latest GIT. Will have to compile the latest to check.

I have only the first two vertical lines, though. XAA acceleration. Desktop system, two screens, only the one connected to the DVI is affected. Resolution is 1280x1024.
Comment 20 Thomas E. Spanjaard 2008-02-28 14:24:21 UTC
Same issue on a X1950XT PCIe R580+. RadeonHD 1.1.0 on X.org server 1.3.0.0, DragonFly BSD 1.11 from january (thus, no acceleration). Cursor corruption in 4 vertical 'bands' perhaps the width of a curser (64 pixels), cursor corruption seems to be made out of just fore- and background cursor colors; not those of the underlying framebuffer. Can provide logs if necessary.
Comment 21 Martin 2008-04-03 08:38:42 UTC
I have this problem, too. Dual-screen setup (only one screen affected, the external monitor, on VGA analog output). The mouse cursor flickers at the last 16 columns of 256 pixel boundaries, e.a. 240-255, 496-511 and so on.

My hardware: Mobility FireGL V5200 (Thinkpad T60p)
Operating system: FreeBSD 7 (STABLE branch)

I guess you can mark the bug platform-independent.
Comment 22 Praveen Kumar 2008-07-22 21:41:30 UTC
Created attachment 17829 [details]
PANEL only Xorg log file - Works fine

This is the Xorg log produced when there is nothing connected to DVI and VGA. This case doesn't seem to have the cursor issue.
Comment 23 Praveen Kumar 2008-07-22 21:43:00 UTC
Created attachment 17830 [details]
DVI+VGA (PANEL closed) Xorg log file - Facing cursor issue

This is the Xorg log file when both DVI and VGA are connected to external LCDs with PANEL closed. This case faces cursor issues.
Comment 24 Praveen Kumar 2008-07-22 21:45:33 UTC
I have this problem too.

Laptop model: Thinkpad T60
Chipset: ATI Mobility Radeon X1300 (R5xx)
Operating System: OpenSolaris 2008.11 snv_93
RadeonHD version: 1.2.1
Xorg version: 1.3

I face the cursor problem when I use dual screen setup (DVI+VGA) with PANEL closed. I don't see this issue when I a using PANEL only. I have posted the Xorg log files of working and issue cases. I am seeing the problem consistently over reboots. I will be more than happy to provide any additional information if required.

Comment 25 Sinisa Dukanovic 2008-07-28 02:45:01 UTC
I'm facing the same problem on a Dell Optiplex 745 Workstation with an "ATI Technologies Inc RV516 [Radeon X1300 Pro]". I'm running a dual monitor setup with both monitors connected to dvi ports and running the same resolution (1280x1024). The cursor distortions only appear on the left (primary) monitor. Just as the aother folks here, i have 3 vertical lined areas, where mouse cursor gets distorted.
Comment 26 Sinisa Dukanovic 2008-07-28 02:46:33 UTC
I just wanted to report, that i have the same issues when using the radeon driver. With fglrx it worked fine. Since the last usage of fglrx, i've had several powercycles.
Comment 27 Yang Zhao 2008-11-07 23:26:37 UTC
Created attachment 20149 [details] [review]
Workaround: leave HW cursor enabled for both CRTCs

Please try if the attached patch solves the corruption problem. Note that it is a workaround, and may not be the correct solution.

There seems to be a bug in how rhdCrtc.Width and rhdCrtc.Height are set, resulting them being set to the full virtual size rather than individual CRTC dimensions. One side effect of this is that when the cursor is in the CRTC on the left, HW cursor for the CRTC to the right is disabled, but the reverse is not true.

With both CRTC enabled but HW cursor active only on one, the reported corruption is seen. If HW cursor for both CRTC is forced to stay on, then no corruption occurs. When the CRTC dimensions were hardcoded to more appropriate values, cursor corruption was seen on both screens.

Oddly enough, there doesn't seem to be any side effects of having HW cursor enabled for both CRTCs even when it is only visible on one.
Comment 28 Pierpaolo Follia 2008-11-24 09:40:58 UTC
I tried the path submitted by Yang Zhao, but the problem is still present on my ATI X1400.
Comment 29 Yang Zhao 2008-11-27 07:17:07 UTC
The new randr cursor code now makes the buggy behaviour happen on both CRTCs. AFAICS, this is expected.

Does anyone have a working setup with fglrx? It would be useful to get some register dumps to see how it's handling the cursor on dual screen.

The following register ranges are relevant: 0x6400-0x6424 and 0x6C00-0x6C24.
Comment 30 Matthias Hopf 2009-02-18 06:20:42 UTC
Bug 19215 is a duplicate, only this time it's on the radeon driver.
Comment 31 Matthias Hopf 2009-02-19 03:43:04 UTC
Pushed Yang's fix in master. Please retest.

For those still having this issue - we could try to use the so called Icon instead of the mouse pointer. It's use has some ugly constraints, that's why we never bothered to implement it.
Comment 32 Alec Habig 2009-02-24 09:53:16 UTC
When starting X the radeonhd driver reports option "HWCursor not used" so I don't know if I'm really testing Yang's fix.

But the cursor corruption is still there with the latest git.

Only on the external monitor (not the laptop panel) if that matters at all.
Comment 33 Matthias Hopf 2009-02-25 06:41:33 UTC
Can you file another log? The message sounds strange...
Comment 34 Alec Habig 2009-02-25 10:15:44 UTC
Created attachment 23289 [details]
Xord.0.log showing HWCursor complaint

Here's the Xorg logfile, not done verbosely (can do so if you want) but it shows the complaint:

  (WW) RADEONHD(0): Option "HWCursor" is not used
Comment 35 Matthias Hopf 2009-02-25 10:39:43 UTC
Ok, that's different. You have
  Option "HWCursor"
in your xorg.conf. radeonhd doesn't have this option, but using hardware cursor is on by default.
Comment 36 aaron 2009-03-05 18:05:20 UTC
as an interesting side note i saw this corruption on windows xp x64 after i was playing "supreme commander forged alliance" and my graphics card restarted itself (i assume... the screens locked up and i heard the fan do the thing it does at boot) crashing the game (it showed a grey screen) and causing all the graphics to "slow down" ie scrolling in ff/ie was painfully slow

i have a x1950xt
Comment 37 Matthias Hopf 2009-04-24 05:59:09 UTC
Alex found something hardware related and I pushed a fix today. It supersedes Yang's fix, so there *could* be regressions.

Can you all please retest?
Comment 38 Ian Pilcher 2009-04-24 15:04:24 UTC
(In reply to comment #37)
> Alex found something hardware related and I pushed a fix today. It supersedes
> Yang's fix, so there *could* be regressions.
> 
> Can you all please retest?
> 

I've built built a new RPM on Fedora 10, using the
xorg-x11-drv-radeonhd-snapshot.sh script.  It says that it was built from
"git commit 8bb8cd80f08d094c8b451e005e57c495dc6e4d42".

I'm still seeing the problem.
Comment 39 Yang Zhao 2009-04-24 15:07:52 UTC
(In reply to comment #38)
> I've built built a new RPM on Fedora 10, using the
> xorg-x11-drv-radeonhd-snapshot.sh script.  It says that it was built from
> "git commit 8bb8cd80f08d094c8b451e005e57c495dc6e4d42".

That's still 2 commits behind.
Comment 40 Yang Zhao 2009-04-24 15:13:45 UTC
Still reproducible by moving the cursor to the other screen, but flickering goes away again by causing the cursor image to change (ie, move to edge of window to activate "resize" cursor)

The places where corruption occur also seems to be different depending on whether the view ports are docked horizontally or vertically.
Comment 41 Ian Pilcher 2009-04-24 15:27:42 UTC
(In reply to comment #39)
> That's still 2 commits behind.

I just re-ran the script, and it came back with the same commit again.

The script appears to be doing

git clone http://yangman.ca/git/xf86-video-radeonhd.git/ xf86-video-radeonhd.src

What command should I be using to get the updated source?
Comment 42 Yang Zhao 2009-04-24 15:40:45 UTC
(In reply to comment #41)
> (In reply to comment #39)
> > That's still 2 commits behind.
> 
> The script appears to be doing
> 
> git clone http://yangman.ca/git/xf86-video-radeonhd.git/
> xf86-video-radeonhd.src

Not sure why your script is pulling from my personal repo instead of the fd.o one.

git://anongit.freedesktop.org/xorg/driver/xf86-video-radeonhd is the URL you want.
Comment 43 Ian Pilcher 2009-04-25 14:40:20 UTC
(In reply to comment #42)
> git://anongit.freedesktop.org/xorg/driver/xf86-video-radeonhd is the URL you
> want.

OK, pulling from that repo definitely gives me different behavior.

The bad news is that I now have a "lingering" mouse pointer on my 1280x1024
display when I move the pointer over to the 1680x1050 display.  The reverse
does not happen.  (I.e. there is no pointer "lingering" on the 1680x1050
display when I move the pointer to the 1280x1024 display.)  I can some-
times get the pointer on the 1280x1024 display to disapper if I move the
mouse from display to display slowly.

The good news is that the mouse pointer "flickering" problem is now mostly
(but not completely) gone.  I also believe that I've only seen it on the
1280x1024 display.
Comment 44 Yang Zhao 2009-04-28 18:00:12 UTC
Looks like Alex agrees that the first workaround is as proper of a fix as we'll get.

I'm working on refactoring the RandR cursor code right now, so I'll incorporate the fix into that and have it finalized and sent to the list in the next couple of days.
Comment 45 Matthias Hopf 2009-04-29 09:41:54 UTC
It seems you're right.
Yang, I removed your code because it seemed to be superfluous. Seems I was wrong.
Comment 46 Alec Habig 2009-05-05 06:52:07 UTC
Today's commit 6f378a0d fixes this issue for me.  Great work guys!
Comment 47 Dragos Delcea 2009-05-05 07:44:53 UTC
(In reply to comment #0)
> using randr, I get a flickering mousecursor in a few well-defined areas
> of one of my screens.
> There are 4 vertical "lines", about 20 pixes in width that go across the
> screen from top to bottom. When I place the mouse cursor on top of these
> "lines", I get a flickering mouse cursor.
> The 4 lines are at about 235-255 pixels from the left edge of the
> screen, at 490-510 pixels from the left edge, at at 940-960 pixels from
> the left edge and at 1005-1025 pixels from the left edge.
> On the other monitor, this does not happen.

> 

I have the flickering behaviour as well. Thinkpad t60, radeon mobility X1400, laptop's panel (1400x1050) + external (VGA connected) Dell 20' display (1680x1050), gentoo 32 bit, xorg 1.5.3, radeonhd 1.2.5.
Now, I see that I should get a git tree in order to get the fix (maybe a quick 1.2.6 follow-up, wink wink), but the funny thing is that I switched to xf86-video-ati (6.12.2) and I'm still seeing the same flickering mouse cursor at well defined areas on the display. So it looks like it's driver independent (or the problematic code is shared). And yeah, I don't remember seeing the flickering when only using the laptop's panel, but the mouse flickers on both panel and external monitor when they're connected.
Comment 48 Alex Deucher 2009-05-05 07:50:30 UTC
(In reply to comment #47)

> I have the flickering behaviour as well. Thinkpad t60, radeon mobility X1400,
> laptop's panel (1400x1050) + external (VGA connected) Dell 20' display
> (1680x1050), gentoo 32 bit, xorg 1.5.3, radeonhd 1.2.5.
> Now, I see that I should get a git tree in order to get the fix (maybe a quick
> 1.2.6 follow-up, wink wink), but the funny thing is that I switched to
> xf86-video-ati (6.12.2) and I'm still seeing the same flickering mouse cursor
> at well defined areas on the display. So it looks like it's driver independent
> (or the problematic code is shared). And yeah, I don't remember seeing the
> flickering when only using the laptop's panel, but the mouse flickers on both
> panel and external monitor when they're connected.
> 

6.12.2 is too old.  the radeon fixes just went in over the last week.
Comment 49 Dragos Delcea 2009-05-05 08:24:09 UTC
> 6.12.2 is too old.  the radeon fixes just went in over the last week.

understood. Is there a release of xf86-video-ati/radeon that has the fix?
I might stick with that for a while, radeonhd still has some issues for me (from time to time I get a NMI - "uh oh..dazed and confused.." and after that either the mouse cursor is severely damaged -a big thumb size rectangle-, or the system freezes hard - don't know if it's related to the bug we're discussing here).
Comment 50 Alex Deucher 2009-05-05 08:34:48 UTC
(In reply to comment #49)
> > 6.12.2 is too old.  the radeon fixes just went in over the last week.
> 
> understood. Is there a release of xf86-video-ati/radeon that has the fix?

No, however, most distros provide git snapshots or you can build from source.
Comment 51 Matthias Hopf 2009-05-06 03:07:51 UTC
All issues should be fixed now with git commit 4be5f7152f71.
Please reopen if issues remain.

Also, please post if it works for you. This has been open so long, that I want to make sure we didn't miss something.
Comment 52 Dragos Delcea 2009-05-07 04:14:47 UTC
(In reply to comment #51)
> Also, please post if it works for you. This has been open so long, that I want
> to make sure we didn't miss something.

tried latest git (commit 4be5f715) and it doesn't flicker anymore, so thumbs up from me.
Comment 53 Thomas E. Spanjaard 2009-05-09 14:41:05 UTC
Commit 4be5f715 solves it for me as well. All cursor corruption is gone (same card as I mentioned earlier in this bug report, but under NetBSD/amd64 5.99.8 this time).
Comment 54 Ian Pilcher 2009-05-10 07:19:39 UTC
Working for me with 4be5f7152f71c292f16b6e30c59c07b282ea4772
Comment 55 Matthias Hopf 2009-05-11 09:35:59 UTC
Seems like the issue is gone for good. Phew!

Thanks for validation!
Comment 56 Tom Pringle 2009-05-11 18:33:19 UTC
These changes made my dual monitor system worse.  Not sure why I'm the only one seeing that.

(In reply to comment #55)
> Seems like the issue is gone for good. Phew!
> 
> Thanks for validation!
> 

Comment 57 Yang Zhao 2009-05-11 21:20:14 UTC
(In reply to comment #56)
> These changes made my dual monitor system worse.  Not sure why I'm the only one
> seeing that.

Can you send some more detailed information to the mailling list or, preferably, drop by the IRC channel? (#radeonhd on freenode).  If it's a really obscure and isolated issue, it'll be easier to debug over a lower latency channel.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.