Comment 41 for bug 22985

Revision history for this message
In , Henry-zhao (henry-zhao) wrote :

<1> The root cause of blank screen without config file is driver fails to
    detect LCD monitor, and thus defaults it to CRT:

    (a) In RADEONQueryConnectedMonitors(), RADEONGetConnectorInfoFromBIOS(pScrn)
        returns non-zero, but it reads DDCType as 0 for both heads, preventing
        RADEONDisplayDDCConnected() from detecting monitor.
    (b) Even if RADEONDisplayDDCConnected() could proceed, it would not be
        able to detect monitor because DDC2 (i2c) probing fails.
    (c) It fails (INREG(RADEON_BIOS_4_SCRATCH) & 4) check for non-DDC laptop
        panel which would otherwise assign MT_LCD to non-DDC DFP/LCD.

    (a) can be solved by using common setting when DDCType of both heads are
    detected 0, i.e.

    if (!RADEONGetConnectorInfoFromBIOS(pScrn) |
        ((pRADEONEnt->PortInfo[0].DDCType == 0) &&
        (pRADEONEnt->PortInfo[0].DDCType == 0))) {
         default common setting
    }

    (b) can be solved with help of VBE DDC probing. In Ferrari 4000 VBE DDC
    probing successfully detects primary head as LCD.

<2> General ideas for the use of VBE DDC probing with radeon driver:

    With radeon driver, VBE DDC probing is helpful when DDC2 probing fails in
    (a) Detecting monitor type; and
    (b) Selecting best mode in mode validation process

    DDC2 probing works for most DFP monitors, plus radeon driver uses
    its own mode validation process that may get mode info corresponding to
    panel size from BIOS/Regs when DDC is not available, and use it in
    validation process, (b) makes most sense for non-DDC CRT monitors. (a) makes
    most sense for laptops because most of them are not DDC capable, and monitor
    info from BIOS are often broken.

    The use of VBE DDC probing as fallback probing method in single head
    situation is always helpful and mostly successful. However, in dual head
    situation there could be a problem of confusion as to which head the
    probing info should apply. Unlike DDC2 probing where you may specify
    the head (or the port) you wish to probe, there is no such mechanism in
    VBE DDC probing. Although probing result is deterministic on a dual head
    system, there is no rule to follow to determine to which head
    the result is to apply, and it varies from one system to another. For
    example, on laptops with external CRT monitor connected, probing info
    applies to LCD on Ferrari 4000, it applies to CRT monitor on Sony Z1WA.

    With the assumption that VBE DDC fallback probing is needed only when
    the display device is laptop LCD or CRT, the logic below will help
    workaround the confusion in dual head systems.

    (a) Always VBE DDC probing primary head, because it may be a laptop LCD
        or a CRT.
    (b) VBE DDC probes secondary head only when it is CRT (
        RADEONCrtIsPhysicallyConnected() can be used to determine that),
        because if it was DFP, DDC2 probing would have succeeded. The
        reason DDC2 does not succeed may be no monitor is connected.
    (c) If a head is CRT, but the VBE DDC probing info says non-analog,
        most likely the probing info should apply to the other head.
    (d) If the primary head is determined as CRT by VBE DDC probed info,
        and it is not CRT but the secondary head is, then the primary head
        could't be CRT since the probed info applies to the second head.
        Therefore the VBE DDC provided monitor info for the primary head should
        be nullified.

<3> I tried the new driver on X300 (RV370) card (with both digital and analog
    ports). On X300 (RV370), the following modes were tested:

    (a) A CRT connected to analog port
    (b) A DFP connected to digital port
    (c) A CRT connected to analog port and A DFP connected to digital port

    All got correct modes without config file. In (c), MergedFB is entered
    at a mode that is the largest common mode between two monitors.

<4> However in Ferrari 4000, in order for RADEONCrtIsPhysicallyConnected()
    to probe analog port correctly (to find out whether a CRT is physically
    connected), you will have to connect a CRT to analog port when booting
    the system. In other words, when a CRT is connected to analog during
    boot, MergedFB mode is entered and a mode that is the largest common
    mode between LCD and CRT is used; if afterwwards the CRT is unplugged,
    LCD alone is running at native mode 1680x1050. On the other hand, if
    the system is booted without a CRT connected, then
    RADEONCrtIsPhysicallyConnected() always incorrectly detects a CRT on
    analog port (even no CRT is connected), resulting in entering MergedFB
    mode even without CRT connected.

    The cause of the problem is when booted without CRT connected, BIOS
    powers down DAC of the analog port, therefore test of CRT connectivity
    will fail since it needs to write and read DAC registers. Another
    consequence is that if a CRT is added later there will be no or very dim
    display. To solve the detection problem, report CRT not being connected
    whent DAC is detected powered down. A more sophisticated solution will be
    addressed in a separate bug.