Bug 13474

Summary: radeonhd: colours transformed on unposted crtc.
Product: xorg Reporter: Stefan Becker <chemobejk>
Component: Driver/radeonhdAssignee: Joachim Deguara <joachim.deguara>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: bugreports, joachim.deguara, thomas.mey
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Screenshot from external display none

Description Stefan Becker 2007-11-30 13:28:56 UTC
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.
Comment 1 Stefan Becker 2007-11-30 13:30:01 UTC
Created attachment 12884 [details]
Screenshot from external display
Comment 2 Thomas Meyer 2007-12-02 05:09:12 UTC
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.
Comment 3 Stefan Becker 2007-12-02 10:44:58 UTC
Confirmed. Switching to text mode and back fixes the problem.

Thanks for the tip.
Comment 4 Joachim Deguara 2007-12-03 09:54:03 UTC
*** Bug 13477 has been marked as a duplicate of this bug. ***
Comment 5 Joachim Deguara 2007-12-03 09:56:46 UTC
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.
Comment 6 Luc Verhaegen 2007-12-11 07:56:39 UTC
Please verify with latest git version. AMDs Lui Wolke spotted a wildly wrong LUTB offset.
Comment 7 Stefan Becker 2007-12-11 08:51:24 UTC
Just reproduced the problem with

commit ae46a18d85fcff03e36c54dc7751469738b6056e

So the LUTB fix didn't help.
Comment 8 Stefan Becker 2007-12-15 13:28:57 UTC
*** Bug 13673 has been marked as a duplicate of this bug. ***
Comment 9 Luc Verhaegen 2007-12-17 16:59:56 UTC
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.
Comment 10 Stefan Becker 2007-12-17 21:55:14 UTC
I have seen the problem on both DVI-I_1 and VGA_1 outputs. So it should not be related to TMDS handling.
Comment 11 Luc Verhaegen 2007-12-18 02:24:47 UTC
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 :)
Comment 12 Soeren Sonnenburg 2007-12-18 02:30:38 UTC
yes the cursor is perfectly OK!
Comment 13 Stefan Becker 2007-12-18 08:31:18 UTC
Confirmed, cursor is perfectly OK. Difficult to see with all this psychedelic colors though :-) 
Comment 14 Luc Verhaegen 2007-12-18 10:57:53 UTC
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.
Comment 15 Luc Verhaegen 2007-12-18 10:59:47 UTC
Err, R600 of course (this is all R500, including mobilities and the RS600/690) 
Comment 16 Luc Verhaegen 2007-12-18 12:27:20 UTC
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.
Comment 17 Stefan Becker 2007-12-18 22:04:59 UTC
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.
Comment 18 Soeren Sonnenburg 2007-12-19 06:05:34 UTC
yes the bug is also still there when using an external tft
Comment 19 Luc Verhaegen 2007-12-19 06:11:06 UTC
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.
Comment 20 Luc Verhaegen 2007-12-19 08:21:26 UTC
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.
Comment 21 Luc Verhaegen 2007-12-19 09:47:03 UTC
Fix has been pushed :)
Comment 22 Soeren Sonnenburg 2007-12-21 10:08:13 UTC
Bug is still there in 1.1.0. :-(

Still as reproducible as non working DDC on this mbp... well.
Comment 23 Luc Verhaegen 2007-12-21 10:27:41 UTC
Macbook only issue, again. Opened a seperate bug for this: https://bugs.freedesktop.org/show_bug.cgi?id=13773
Comment 24 Stefan Becker 2008-01-09 14:04:59 UTC
Retested with

 (II) RADEONHD: version 1.1.0, built from git branch master, commit 4e488a34

Problem is still there.
Comment 25 Joachim Deguara 2008-01-24 14:47:24 UTC
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).
Comment 26 Soeren Sonnenburg 2008-01-24 21:32:06 UTC
(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 ? 

Comment 27 Stefan Becker 2008-01-24 21:47:22 UTC
Nope, I'm using a Lenovo Thinkpad T60.

I haven't tried the xgamma trick yet. I can fix the problem with VT switching.
Comment 28 Joachim Deguara 2008-01-25 09:14:50 UTC
(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.
Comment 29 Egbert Eich 2008-03-27 10:01:13 UTC
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.
Comment 30 Egbert Eich 2008-07-30 10:03:55 UTC
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.
Comment 31 Egbert Eich 2008-07-31 13:55:16 UTC
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 ***
Comment 32 Luc Verhaegen 2008-11-18 06:59:18 UTC
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.