I've just tried KMS on my RV635 and my old D-SUB (analog) LCD displays colors incorrectly when using DVI-0. When switching to DVI-1 it works fine.
Any idea what can be a reason? In both cases we use INTERNAL_KLDSCP_DACx.
Created attachment 33810 [details]
Created attachment 33811 [details]
colors1 bad (photo)
Created attachment 33812 [details]
colors1 good (screenshot)
Created attachment 33813 [details]
colors2 bad (photo)
Created attachment 33814 [details]
colors2 good (screenshot)
Does UMS work ok? I suspect it's the bg/adj values for the dac.
(In reply to comment #6)
> Does UMS work ok? I suspect it's the bg/adj values for the dac.
At least radeonhd does work fine for both DVIs. Will test radeon soon.
Can you point me to some part of code or registers that I can compare?
Do we really submit other data for AtomBIOS DAC-controlling commands at all?
(In reply to comment #7)
> (In reply to comment #6)
> > Does UMS work ok? I suspect it's the bg/adj values for the dac.
> At least radeonhd does work fine for both DVIs. Will test radeon soon.
> Can you point me to some part of code or registers that I can compare?
> Do we really submit other data for AtomBIOS DAC-controlling commands at all?
The bg/dac adj values are golden values set in the atombios dac command tables. It might be a bug in the kms atom parser (I've fixed several of them recently) or a bad paramater passed to one of the tables, or something else completely unrelated. Make sure your kms tree has this patch:
I'd suggest using avivotool to dump the regs and compare. The dac regs are at 0x7000-0x706c,0x7ef0-0x7ef8 (DAC1) and 0x7100-0x716c,0x7ff0-0x7ff8 (DAC2)
the second set in each group are the dac bgadj and macro regs.
I use drm-linus which contains "fix shr/shl ops".
Thanks a lot for giving registers! It gave nice results :)
# diff -u bad.log ok.log
--- bad.log 2010-03-06 20:54:42.288325112 +0100
+++ ok.log 2010-03-06 20:52:30.060416677 +0100
@@ -52,7 +52,7 @@
@@ -66,5 +66,5 @@
rhd_dump: v1.3.0, git branch master, commit d6631a8c
# rhd_dump -w 0x7FF4 0x00202902 1:00.0
It made the trick. Now need just to find out why 0x7FF4 had incorrect value...
Created attachment 35168 [details]
Can be duplicate of bug #27478, will try to check if I'll get access to this RV635.
This is indeed a duplicate of bug 27478.
*** This bug has been marked as a duplicate of bug 27478 ***