Version information: (II) RADEONHD: version 1.0.0, built from git branch master, commit 9fe776ed xrandr: commit 4bc84c331f4f0f0658ad1f6c0107e3e6af2a7911 HW information: Lenovo T60 with 1400x1050 panel #./rhd_conntest -d 01:00.00 rhd_conntest: v1.0.0, git branch master, commit 9fe776ed Checking connectors on 0x7149, 0x17AA, 0x2005 (@01:00:00): Load Detection: RHD_OUTPUT_NONE HotPlug: RHD_HPD_NONE DDC: RHD_DDC_2 LVDS Info: 18bits, dual link, LDI Panel found. Power Timing: 0xF9F, 0x00F, 0x28, 0x2D, 0x0A8 Macro: 0x0C720407, Clock Pattern: 0x0063 External display is either dataprojector connected to VGA or a Samsung DLP TV connected via DVI. Steps to reproduce the problem: 1) Start X server - with or without external display connected 2) enable/disable clone output to external display with xrandr 3) suspend laptop 4) resume laptop 5) enable/disable clone output to external display with xrandr Results: 2) Works like a charm! GREAT :-) 5) external display shows content with colors completely junk :-( This is always reproducible.
Created attachment 12884 [details] Screenshot from external display
I can produce a screen like in this attachment: 1.) no x server is running. vga-console only. start the x server without external monitor connected via "startx". 2.) x server is up and running. connect external monitor and do "xrandr --auto". 3.) now the screen displayed on the external monitor looks like the screen in the attachment. 4.) switching to vga console and to the x server again, corrects the bad color image.
Confirmed. Switching to text mode and back fixes the problem. Thanks for the tip.
*** Bug 13477 has been marked as a duplicate of this bug. ***
Confirmed for me also that switching to console (which is actually a different card in my system!) and back fixes the problem for me. The one difference is from Stefan and like Thomas for me is that I do not need to do suspend/resume at all to get bad colors it is just going from clone to dual-head.
Please verify with latest git version. AMDs Lui Wolke spotted a wildly wrong LUTB offset.
Just reproduced the problem with commit ae46a18d85fcff03e36c54dc7751469738b6056e So the LUTB fix didn't help.
*** Bug 13673 has been marked as a duplicate of this bug. ***
As a first important datapoint, can you all echo which output you are using? Is there a line in this? Stefan seems to be using TMDSA, but i have no idea about what output this is occuring on for Thomas, Joachim or soeren. This is important as i need to know whether this is an output or Crtc specific issue.
I have seen the problem on both DVI-I_1 and VGA_1 outputs. So it should not be related to TMDS handling.
Ok, so this is not an output issue at all, but something i probably missed in setting up one of the engines in the CRTC. Is the cursor ok when this happens or not? It is unclear from your shot whether it is or isn't. Joachims shot has no cursor, and i cannot find it on soerens shot, although that could just mean that it is too broken :)
yes the cursor is perfectly OK!
Confirmed, cursor is perfectly OK. Difficult to see with all this psychedelic colors though :-)
Ok, i have spotted a possible cause, but i can only trigger it on R600 and above (not even on rs690). will commit a fix soon. But please state when you have a device which is < RS690.
Err, R600 of course (this is all R500, including mobilities and the RS600/690)
I pushed something up which should tighten the register usage in the GRPH engines, i hope that this will fix at least some of the issues seen here.
Just retried with $ fgrep commit /var/log/Xorg.0.log (II) RADEONHD: version 1.0.0, built from git branch master, commit 861debbf on a external VGA: still the same problem.
yes the bug is also still there when using an external tft
Ok, can i get a log (logverbose 7) of this happening? I doubt that we are missing a call when enabling the new CRTC, but it would be interesting to find out.
Reproduced it here now: * attached external. * xrandr --auto enabled it ok. * detached external. * xrandr --auto disabled it. * powersave -u * resume again. * attached external again. * xrandr re-enables, and then colours are broken. But... A better fix has been found now: if i run xgamma, the problem goes away. I am going to dig into what i am doing wrong here, but i am very very very close.
Fix has been pushed :)
Bug is still there in 1.1.0. :-( Still as reproducible as non working DDC on this mbp... well.
Macbook only issue, again. Opened a seperate bug for this: https://bugs.freedesktop.org/show_bug.cgi?id=13773
Retested with (II) RADEONHD: version 1.1.0, built from git branch master, commit 4e488a34 Problem is still there.
I am still having this problem also. The mouse looks absolutely fine it is just the rest of the screen. The mouse is white and black (I know how boring) but if I create something in gimp that is white and black then it appears as green and dark purple respectively. I am using commit bc8851304 BTW `xgamma -gamma 1.0` does the trick to clear up the color distortion for me to (just like in comment #20).
(In reply to comment #25) > I am still having this problem also. The mouse looks absolutely fine it is > just the rest of the screen. The mouse is white and black (I know how boring) > but if I create something in gimp that is white and black then it appears as > green and dark purple respectively. > I am using commit bc8851304 > > BTW `xgamma -gamma 1.0` does the trick to clear up the color distortion for me > to (just like in comment #20). Aha. Are you too on a macbookpro ?
Nope, I'm using a Lenovo Thinkpad T60. I haven't tried the xgamma trick yet. I can fix the problem with VT switching.
(In reply to comment #26) > (In reply to comment #25) > > I am still having this problem also. The mouse looks absolutely fine it is ... > > Aha. Are you too on a macbookpro ? > No I am not on macbookpro. Tyan 2915 mainboard with 2900XT graphics card.
Joachim, could you please send a verbose log of the server where this happens? (-logverbose 7). Assigning to reporter for feedback. Please assign back when done.
Looking at the bug list, could this actually be a duplicate of bug #16280? The remaining problem in #15521 could actually be related to this, too.
I've talked Joachim who also thinks that this is a duplicate of bug #16280. *** This bug has been marked as a duplicate of bug 16280 ***
Should be fixed with 41d4bf718b4
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.