Using xserver 1.4 and xf86-video-ati from git (tried both master and atombios-support branch): On my notebook (Mobility Radeon X700) the internal panel does not work correctly if a CRT is connected on boot. When X is started, the panel will be detected but display all white. (While on the console, the internal panel will remain dark.) However, if the CRT is connected after the system has started, the internal panel works fine. In Xorg.0.log there is one interesting difference: --- -(II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=50000; xclk=40000 +(II) RADEON(0): PLL parameters: rf=2700 rd=7 min=20000 max=50000; xclk=40000 --- Full logs will be attached.
Created attachment 12959 [details] Xorg.0.log-CRT-connected-on-boot
Created attachment 12960 [details] Xorg.0.log-CRT-connected-after-boot
Created attachment 12961 [details] Xorg.0.log-atombios-CRT-connected-on-boot This is the log when using the atombios-support branch from xf86-video-ati git
Created attachment 12962 [details] Xorg.0.log-atombios-CRT-connected-after-boot
Does it work better if you revert commit b368b0f22cd1d7ef9b4c65d82929c76f3b82d573 on the atombios branch?
(In reply to comment #5) No, reverting that commit makes no difference.
I think bug 12913 and bug 13533 may be related. It seems pll 0 has issues that may be related to bios init.
*** This bug has been marked as a duplicate of bug 12913 ***
The fix for bug 12913 does not correct the LVDS all white issue. In fact, it makes things worse for me (bug 12913 comment 15). It seems that the PLL issue is not related to this bug.
does the current master ati tree (as of a84d446fd301d456bcea8f7abdc52e5a30776412) work for you? does reverting that commit help? Can you also try the atombios-support branch? I have some additional pll tweaks there that may be required.
commit a84d446fd301d456bcea8f7abdc52e5a30776412 solves the distorted display issue in bug 12913 comment 15, but breaks vt switching with radeonfb when a CRT is connected on boot (the CRT will go dark after pressing Ctrl+Alt+F1). Will try without radeonfb later. The LVDS is still all white.
Created attachment 13113 [details] radeontool-regmatch-all-crt-connected-on-boot output of radeontool regmatch '*' when a crt is connected on boot
Created attachment 13114 [details] radeontool-regmatch-all-crt-connected-after-boot output of radeontool regmatch '*' when a crt is connected after boot
Created attachment 13116 [details] radeondump-output radeondump output and diff for both cases
Does commenting out line 4040 (OUTREG(RADEON_LVDS_PLL_CNTL, restore->lvds_pll_cntl);) of radeon_driver.c from ati git master help?
I think I've fixed this. Can you test again with ati git master?
Unfortunately, the problem still exists with current git master.
Created attachment 13146 [details] radeontool-regmatch-all-crt-connected-on-boot
Created attachment 13147 [details] radeontool-regmatch-all-crt-connected-after-boot radeontool output with current git master
Can you try again with ati git master (commit 653da558148cc601bc1f80253e92ef98c75ef37a)?
Tried current git, no difference.
Is this still an issue with a newer driver (6.9.0 or newer)?
The issue still exists with a git checkout from today.
With xf86-video-ati-6.12.1 and the R4xxATOM option enabled, the situation is now better. The LVDS now shows a picture, the same as the VGA-0. I can turn on and off LVDS and VGA-0 independently with xrandr. Remaining issues: The VGA-0 is always driven at 1280x800 (the internal panel's resolution), no matter what I set in xrandr. xrandr even wrongly claims that VGA-0 is running at a different resolution when in fact it is not. VGA-0 and LVDS always display the same content. If I change the monitor layout eg. with xrandr --output VGA-0 --right-of LVDS then both displays show what LVDS should show. With R4xxATOM disabled, the situation is the same as before.
Some additional information: The R4xxATOM problem that LVDS and VGA-0 always show the same contents and have the same mode is independent on whether a CRT was connected on boot. I will open a separate bug for this. If I start X with R4xxATOM enabled, then start again with R4xxATOM disabled, then the problem is fixed, the LVDS is no longer all white and I can use xrandr to set different modes to the displays.
(In reply to comment #25) > If I start X with R4xxATOM enabled, then start again with R4xxATOM disabled, > then the problem is fixed, the LVDS is no longer all white and I can use xrandr > to set different modes to the displays. > can you attach register dumps using radeontool (http://cgit.freedesktop.org/~airlied/radeontool) before running with R4xxATOM and after? (as root): (start with broken state) ./radeontool regmatch '*' > before.dump (switch to R4xxATOM) ./radeontool regmatch '*' > after.dump
Created attachment 24191 [details] before.dump output of radeontool regmatch '*' in broken state with R4xxATOM disabled
Created attachment 24192 [details] after.dump output of radeontool regmatch '*' in working state with R4xxATOM enabled
Created attachment 24193 [details] finally.dump output of radeontool regmatch '*' in working state with R4xxATOM disabled, after X was previously started with R4xxATOM enabled
this should be fixed in: 5a7c9d94733a0db1d3565447acc9f0e751db5950
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.