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] dmesg.log
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: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6a8a2d702b33c6ed5c789f21b4e89fdf221f01ca 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 @@ 0x7134: 0x02020200 0x7138: 0x00000000 0x713C: 0x00000000 -0x7140: 0x000001E6 +0x7140: 0x00000000 0x7144: 0x00000000 0x7148: 0x00000000 0x714C: 0x00000000 @@ -66,5 +66,5 @@ 0x716C: 0x00000000 rhd_dump: v1.3.0, git branch master, commit d6631a8c 0x7FF0: 0x00000020 -0x7FF4: 0x00200102 +0x7FF4: 0x00202902 0x7FF8: 0x00700251 # 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] RV635 ROM
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 ***
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.