Hi, I have an Apple 30" display and X1650 PCIe. 1280x800 works fine, but 2560x1600 generates corruption, as shown as in the two attached screenshots. airlied and agd5f helped on IRC, and we tried a few things: * it's not DRM; same happens with DRM off. * turning ColorTiling off doesn't help. * it's not a sync polarity problem. * it's not a regression; although this was working on ajax's monitor around Nov 20th, a Nov 20th checkout doesn't work here. * it *does* work in fglrx. Log attached. Tomorrow I'll run "avivotool regs all" with fglrx and radeon and attach that.
Created attachment 13628 [details] Photo after running "X"
Created attachment 13629 [details] Photo after logging in
Created attachment 13630 [details] Xorg.0.log
Created attachment 13631 [details] xorg.conf
Created attachment 13648 [details] avivotool regs all, under fglrx
Created attachment 13649 [details] avivotool regs all, under radeon
Created attachment 13654 [details] regs all diff from radeon to fglrx
I have this fixed now! I don't yet understand the fix, though. I noticed that radeon worked when run *after* fglrx, which made things a lot easier -- fglrx was obviously changing a necessary register that radeon doesn't touch. Finding that register was difficult; the <0x1000 registers weren't helping anything, and the "regs all" diff between radeon-before-fglrx (failing case) and radeon-after-fglrx (working case) had >100 registers in. I wrote a perl script which takes two "avivotool regs all" dumps, the first assumed to be the working state and the second assumed to be the bad state, and sets every register currently in the bad state to the good state, with a one second delay between each regset for you to see whether it fixed the problem on the screen. The script is here: http://dev.laptop.org/~cjb/apply-regs-diff.pl This found the culprit register, which is a set of two: 0x6590 (which radeon_reg.h knows to be AVIVO_D1SCL_SCALER_ENABLE) and 0x6594. Neither of these are touched by radeon, but the problem state is when they are set; fglrx clears them, and they aren't changed by radeon at all. The default state at bootup, before any drivers have been loaded, is for them to be set. So, the attached works-for-me patch clears just those two registers at load-time. The placement in atombios_crtc.c is just a guess, and I haven't commented the writes because I don't expect them to be committed while 0x6594 remains magic. How would I learn more about these registers? The AMD docs don't seem to cover them. By the way, I'm sure other people have similar tools to my perl script, but I don't know where any are. You're welcome to include my script with avivotool/radeontool if you'd like to.
Created attachment 13678 [details] [review] Patch to clear scaler registers
Created attachment 13683 [details] [review] atom scaler code Does this patch help? This will disable the scaler if scaling is not enabled. Enabling doesn't work just yet.
(In reply to comment #10) > Does this patch help? This will disable the scaler if scaling is not enabled. > Enabling doesn't work just yet. Yep, works, thanks. Can your patch be committed?
committed. thanks!
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.