Created attachment 29436 [details]
BAD: rhd_dump -l 0

Created attachment 29437 [details]
BAD: rhd_dump -l 1

Created attachment 29438 [details]
BAD: rhd_dump -r 0,7fff

Created attachment 29439 [details]
OK: rhd_dump -l 0

Created attachment 29440 [details]
OK: rhd_dump -l 1

Created attachment 29441 [details]
OK: rhd_dump -r 0,7fff

Created attachment 29442 [details]
Photo of monitor with broken colors

Created attachment 29443 [details]
Xorg.0.log from OK

Created attachment 29444 [details]
xrandr output from BAD

Yeah, LUT on CRTC1 is completely messed up.

Please try reproducing it with the latest from git.  I recently did a rewrite of the LUT loader.

(In reply to comment #10)
> Yeah, LUT on CRTC1 is completely messed up.
> 
> Please try reproducing it with the latest from git.  I recently did a rewrite
> of the LUT loader.

Check my Xorg.0.log, I'm using ca1e34f85387bdf3eb1727d2fb628e4774f893a1.

This is old-known bug for me, so it is not regression caused by your rewrite.

(In reply to comment #11)
> (In reply to comment #10)
> > Yeah, LUT on CRTC1 is completely messed up.
> > 
> > Please try reproducing it with the latest from git.  I recently did a rewrite
> > of the LUT loader.
> 
> Check my Xorg.0.log, I'm using ca1e34f85387bdf3eb1727d2fb628e4774f893a1.

That's a commit local on your working branch.

 
> This is old-known bug for me, so it is not regression caused by your rewrite.

I wouldn't expect there to be a regression.  Just checking if it's something that's already fixed.

Is some one having a bad day or have you a problem?
Please RSVP, Tar SEanS

On 13/09/2009, bugzilla-daemon@freedesktop.org
<bugzilla-daemon@freedesktop.org> wrote:
> http://bugs.freedesktop.org/show_bug.cgi?id=23877
>
>
>
>
>
> --- Comment #12 from Yang Zhao <yang@yangman.ca>  2009-09-13 12:57:20 PST
> ---
> (In reply to comment #11)
>> (In reply to comment #10)
>> > Yeah, LUT on CRTC1 is completely messed up.
>> >
>> > Please try reproducing it with the latest from git.  I recently did a
>> > rewrite
>> > of the LUT loader.
>>
>> Check my Xorg.0.log, I'm using ca1e34f85387bdf3eb1727d2fb628e4774f893a1.
>
> That's a commit local on your working branch.
>
>
>> This is old-known bug for me, so it is not regression caused by your
>> rewrite.
>
> I wouldn't expect there to be a regression.  Just checking if it's something
> that's already fixed.
>
>
> --
> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug.
> _______________________________________________
> xorg-team mailing list
> xorg-team@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-team
> --
> To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org
> For additional commands, e-mail: radeonhd+help@opensuse.org
>
>

(In reply to comment #12)
> > Check my Xorg.0.log, I'm using ca1e34f85387bdf3eb1727d2fb628e4774f893a1.
> 
> That's a commit local on your working branch.

Err, no? http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/commit/?id=ca1e34f85387bdf3eb1727d2fb628e4774f893a1 :)

So to make it clear, I use:

commit ca1e34f85387bdf3eb1727d2fb628e4774f893a1
Author: Luc Verhaegen <libv@skynet.be>
Date:   Tue Sep 8 17:22:57 2009 +0200

    Revert "Fix softlocks on rs690. Idle commands have to be flushed to be of any use."

    This reverts commit d8329927aaac5f2d4949785951326ebc782bc420

Ah, oops, my local copy wasn't up-to-date.

So this is intermittent, and only affects CRTC1?

Does changing the gamma using `xradr --gamma ...' fix the corruption?

(In reply to comment #15)
> So this is intermittent, and only affects CRTC1?

Right, I've never seen that on PANEL which is controlled by CRTC0. I experienced this using HDMI controlled by CRTC1 using two different HDTVs: Samsung and Sony.


> Does changing the gamma using `xradr --gamma ...' fix the corruption?

Interesting, it did. I used "xrandr --gamma 0.9" and it fixed problem. Then I gone back to "xgamma --gamma 1.0" and it was still fine.

Created attachment 29869 [details]
rhd_dump -l 1 when broken colors on Samsung HDTV

Created attachment 29870 [details]
rhd_dump -l 1 with gamma-fixed colors on Samsung HDTV

After xgamma --gamma 0.9

Created attachment 29872 [details] [review]
Fix RHDLUTCopyForRR() being no-op

Try the attached patch.  It's for something that needs to be fixed anyway, but seeing what effect it has on this bug may be useful.

Don't worry about having to attach the dumps in the future: it was enough to confirm that the tables are messed up.

(In reply to comment #19)
> Created an attachment (id=29872) [details]
> Fix RHDLUTCopyForRR() being no-op

The correct version of this is now in master.

(In reply to comment #20)
> (In reply to comment #19)
> > Created an attachment (id=29872) [details] [details]
> > Fix RHDLUTCopyForRR() being no-op
> 
> The correct version of this is now in master.

I had to find some reliable way of reproducing this bug first, to be able to test your patch. Sorry it took so long, I've been quite busy.

So that corrupted colors happens only after very cold boot. If I switch to console even once, or restart X even once, or suspend&resume even once, this is not reproducible anymore. Please note, I've mention cold boot. That means that "init 6" is not enough to reproduce this bug. I've to do "init 0 && sleep 3s".

So finally having way of reproducing this I've made 5 tests on 8b3561d2aabeed34c77d9845e2f9814de8375bed and f695445b386050de346211baec5e487813187cfd.

Starting from:

commit f695445b386050de346211baec5e487813187cfd
Author: David Morrison <dave@bnl.gov>
Date:   Tue Oct 6 11:13:26 2009 -0700

    LUT: Fix syntax error in 59085c4a

this bug doesn't appear anymore.

Thank you very much for fixing this :)

*** Bug 23596 has been marked as a duplicate of this bug. ***