Bug 1514 - [ATI/radeon] monitor resolution/frequency is locked
Summary: [ATI/radeon] monitor resolution/frequency is locked
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 6.8.1
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact:
: 1175 (view as bug list)
Depends on:
Reported: 2004-10-03 02:16 UTC by Dams
Modified: 2005-09-24 11:27 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:

output of /var/log/xorg.log (60.26 KB, text/plain)
2004-10-09 20:13 UTC, T. Scott Talbot
no flags Details

Description Dams 2004-10-03 02:16:51 UTC
I'm currently using Fedora Core development tree, which has xorg-x11 6.8.x
package set. The problem is that whatever the choosen resolution the monitor
seems locked in a 1920x1440-ish resolution at a low refresh rate. The root
window is at the choosen resolution, doesnt cover the whole screen and is
located at the left top corner of the screen.

Pressing ctrl-alt-+/- doent help. It does change the root window size, but the
monitor is at the same resolution/frequency.

The same configuration file works very well with X11 6.7.0 (X11 packages from
fedora core 2, installed on the development tree environment)

My hardware is an old AGP Radeon 7200 which has always worked well since radeon
was supported in XFree86. Here is the lspci -vvv output for the card : 

01:05.0 VGA compatible controller: ATI Technologies Inc Radeon R100 QD [Radeon
7200] (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc Radeon 7000/Radeon
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2000ns min), Cache Line Size 08
        Interrupt: pin A routed to IRQ 201
        Region 0: Memory at f4000000 (32-bit, prefetchable) [size=64M]
        Region 1: I/O ports at d800 [size=256]
        Region 2: Memory at f1800000 (32-bit, non-prefetchable) [size=512K]
        Expansion ROM at f3fe0000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
                Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Monitor is a 22" Mitsubishi Diamond Plus 230SB. Here is the "kudzu -p -b ddc"
output : 
class: VIDEO
bus: DDC
detached: 0
driver: unknown
desc: "ATI Technologies Inc. RG6"
mem: 32768
class: MONITOR
bus: DDC
detached: 0
driver: unknown
desc: "Mitsubishi Diamond Plus 230SB"
id: MEL4631
horizSyncMin: 30
horizSyncMax: 115
vertRefreshMin: 50
vertRefreshMax: 160
mode: 640x480
mode: 800x600
mode: 1024x768
mode: 1152x864
mode: 1280x1024
mode: 1600x1200
mode: 1792x1344
mode: 1920x1440

This bug as already been filled in redhat bugzilla : 
Configuration file can be found at 
and output Xorg.0.log can be found at 

Feel free to ask me any additionnal detail.
Comment 1 Mike A. Harris 2004-10-09 14:51:08 UTC
*** Bug 1175 has been marked as a duplicate of this bug. ***
Comment 2 T. Scott Talbot 2004-10-09 20:13:35 UTC
Created attachment 1057 [details]
output of /var/log/xorg.log

line reading:
(WW) RADEON(0): Failed to set up write-combining range (0xe0000000,0x4000000)
(II) RADEON(0): Dynamic Clock Scaling Disabled
hopefully will assist in resolving bug.
Comment 3 Mike A. Harris 2004-10-12 16:16:04 UTC
(II) RADEON(0): Validating modes on Primary head ---------
(II) RADEON(0): Panel size found from DDC: 1920x1440

This is interesting.  Is this a monitor (CRT) or an LCD/DFP display?
Since this is reported for Radeon 7200, I'm assuming it is a monitor,
so it shouldn't be detecting a panel size per se.

On a separate note, are you using 'rhgb' to boot?  (Graphical boot)
If so, please try disabling rhgb, and rebooting the machine and trying
to reproduce this issue.  Report back your findings.

Thanks in advance.
Comment 4 Mike A. Harris 2004-10-12 16:20:17 UTC
If disabling rhgb and rebooting works around this problem, then it
might possibly be DRI/multi-X-server related. If this stops the
problem from occuring, boot into runlevel 3, then run startx on
display :0 with DRI enabled, and a second copy of startx on :1
to see if it hangs.
Comment 5 Mike A. Harris 2004-10-13 04:54:45 UTC
It definitely looks like the radeon display detection code is screwy here.
Comment 6 Mike A. Harris 2004-10-13 05:26:26 UTC
(II) RADEON(0): I2C bus "DDC" initialized.
(II) RADEON(0): Legacy BIOS detected
(WW) RADEON(0): No Connector Info Table found!

This seems related to the problem.  It appears it can't find the connector
table in the BIOS, and then guesses wrong that it is a flat panel display,
but it is really a CRT.

Hui, Michel:  Any thoughts?
Comment 7 Mike A. Harris 2004-10-13 05:39:15 UTC
RADEONQueryConnectedMonitors() calls RADEONGetConnectorInfoFromBIOS() which
fails with FALSE in the following code for a LegacyBIOS:

    } else {
        if ((tmp = RADEON_BIOS16(info->ROMHeaderStart + 0x50))) {
            for (i = 1; i < 4; i++) {

                if (!RADEON_BIOS8(tmp + i*2) && i > 1) break; /* end of table */

                tmp0 = RADEON_BIOS16(tmp + i*2);
                if (((tmp0 >> 12) & 0x1f) == 0) continue; /* no connector */

                /* internal DDC_DVI port will get assigned to PortInfo[0], or if
there is no DDC_DVI (like in some IGPs). */
                tmp1 = ((((tmp0 >> 8) & 0xf) == DDC_DVI) || (tmp1 == 1)) ? 0 :
1; /* determine port info index */

                pRADEONEnt->PortInfo[tmp1].DDCType        = (tmp0 >> 8) & 0x0f;
                if (pRADEONEnt->PortInfo[tmp1].DDCType > DDC_CRT2)
                pRADEONEnt->PortInfo[tmp1].DACType        = (tmp0 & 0x01) ?
                pRADEONEnt->PortInfo[tmp1].ConnectorType  = (tmp0 >> 12) & 0x0f;
                if (pRADEONEnt->PortInfo[tmp1].ConnectorType >
CONNECTOR_UNSUPPORTED) pRADEONEnt->PortInfo[tmp1].ConnectorType =
                pRADEONEnt->PortInfo[tmp1].TMDSType       = ((tmp0 >> 4) & 0x01)

                /* some sanity checks */
                if (((pRADEONEnt->PortInfo[tmp1].ConnectorType !=
                     (pRADEONEnt->PortInfo[tmp1].ConnectorType !=
                    pRADEONEnt->PortInfo[tmp1].TMDSType == TMDS_INT)
                    pRADEONEnt->PortInfo[tmp1].TMDSType = TMDS_UNKNOWN;

                xf86DrvMsg(0, X_INFO, "Connector%d: DDCType-%d, DACType-%d,
TMDSType-%d, ConnectorType-%d\n",
                           tmp1, pRADEONEnt->PortInfo[tmp1].DDCType,
        } else {
            xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "No Connector Info Table
            return FALSE;

This causes the Connector Info Table message we see in the log file to
get output.  Back in RADEONQueryConnectedMonitors(), the following is
what is executed for this block above:

    if (!RADEONGetConnectorInfoFromBIOS(pScrn)) {
        /* Below is the most common setting, but may not be true */
        pRADEONEnt->PortInfo[0].MonType = MT_UNKNOWN;
        pRADEONEnt->PortInfo[0].MonInfo = NULL;
        pRADEONEnt->PortInfo[0].DDCType = DDC_DVI;
        pRADEONEnt->PortInfo[0].DACType = DAC_TVDAC;
        pRADEONEnt->PortInfo[0].TMDSType = TMDS_INT;
        pRADEONEnt->PortInfo[0].ConnectorType = CONNECTOR_DVI_D;

        pRADEONEnt->PortInfo[1].MonType = MT_UNKNOWN;
        pRADEONEnt->PortInfo[1].MonInfo = NULL;
        pRADEONEnt->PortInfo[1].DDCType = DDC_VGA;
        pRADEONEnt->PortInfo[1].DACType = DAC_PRIMARY;
        pRADEONEnt->PortInfo[1].TMDSType = TMDS_EXT;
        pRADEONEnt->PortInfo[1].ConnectorType = CONNECTOR_CRT;

The comment there "Below is the most common setting, but may not be true"
definitely seems to not be true for a Radeon 7200, as it has one single
head, and is not DVI.
Comment 8 Mike A. Harris 2004-10-13 05:45:40 UTC
I think 2 things could/should be done in this case..  The first is to
fix the BIOS detection code to handle this card's BIOS table correctly,
so that the broken fallback path doesn't get taken.  Since the driver
worked in previous releases of X, this should be possible I'm assuming.

The second would be to fix the fallback to perhaps be a bit more sane?
Or perhaps to make the fallback PCI ID specific?

Any thoughts?
Comment 9 Mike A. Harris 2004-10-13 06:05:34 UTC
Discussed this with Anvil in IRC a bit.  I got him to try:

Option "MonitorLayout" "CRT,None" and that got past this problem but
the server crashed with a different error/bug.

Anvil:  Can you file a new bug report for the new bug that occurs when
you use MonitorLayout, and attach the config file and log file, and
carbon copy me on it?  TIA

Comment 10 Mike A. Harris 2004-10-13 06:06:31 UTC
Here's another reference to this problem, copied over from bug #1175 for

Comment 11 HUI YU 2004-10-13 06:33:11 UTC
Thanks Mike for the heads up. 
It looks like a DDC detection problem, there are several related bugs in the 
Bugzilla. I remember I tested two 7200 cards (one normal and one AIW) when xorg 
6.8 was about to release, they all worked fine. I haven't tried xorg code since 
then. I'll take some time in next few days to revisit this issue according to 
all the recent bug reports. 
Comment 12 T. Scott Talbot 2004-10-13 07:18:22 UTC
Thanks for the help!
I don't believe I got any of my CCs (have to check that) anyway:
#3 device is LCD panel (Samsung SyncMaster 193P)
    Tried w/O RHGB, no change, Tried startx from level 3 = no change
Comment 13 HUI YU 2004-10-15 12:43:28 UTC
Please try the patch I posted in Bug #1622, the patch should fix this 7200 
problem too. Please test it, thx. 
It's normal for R7200 failing connector detection, old version of BIOS doesn't 
support it. 
The dual-head issue is different, I'll look at that later.
Comment 14 Kevin E. Martin 2004-10-18 16:44:53 UTC
I've tested the patch from bug 1559 with the 7200 I have here, and it fixes the
detection problems.

I still need to test it on other cards to make sure there are no regressions.
Comment 15 Mike A. Harris 2004-10-19 23:08:01 UTC
Red Hat bug report, for cross referencing:

Comment 16 T. Hood 2005-09-23 08:20:13 UTC
(In reply to comment #14)
> I've tested the patch from bug 1559 with the 7200 I have here, and it fixes the
> detection problems.
> I still need to test it on other cards to make sure there are no regressions.

Is this bug fixed now?
Comment 17 T. Hood 2005-09-25 04:27:08 UTC
As the original submitter (Dams) doesn't reply, presumed fixed.

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.