Summary: | radeonhd: colours transformed on unposted crtc. | ||||||
---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Stefan Becker <chemobejk> | ||||
Component: | Driver/radeonhd | Assignee: | 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
Stefan Becker
2007-11-30 13:28:56 UTC
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.