Bug 5473 - Blank screen with Radeon Mobility X700 (Acer Ferrari 4005)
Summary: Blank screen with Radeon Mobility X700 (Acer Ferrari 4005)
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.1 (2006.05)
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: patch
: 7559 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-01-02 03:00 UTC by Nicolas George
Modified: 2007-10-30 04:54 UTC (History)
14 users (show)

See Also:
i915 platform:
i915 features:


Attachments
server log (38.90 KB, text/plain)
2006-01-02 03:01 UTC, Nicolas George
no flags Details
Fixes to improve monitor type detection and monitor probing for radeon driver (5.30 KB, patch)
2006-06-08 22:17 UTC, henry.zhao@oracle.com
no flags Details | Splinter Review
The "gitified" patch (5.54 KB, patch)
2006-06-17 02:41 UTC, Erik Andren
no flags Details | Splinter Review
Xorg log without the patch applied (50.87 KB, text/x-log)
2006-06-17 02:42 UTC, Erik Andren
no flags Details
Xorg log with the patch applied (58.52 KB, text/x-log)
2006-06-17 02:42 UTC, Erik Andren
no flags Details
Revision to fixes to improve monitor type detection and monitor probing for radeon driver (5.86 KB, patch)
2006-06-22 17:38 UTC, henry.zhao@oracle.com
no flags Details | Splinter Review
Xorg.0.log with patch from latest git (X700 / HP NW8240 laptop) (41.38 KB, text/plain)
2006-08-31 22:23 UTC, Martijn van de Streek
no flags Details
Correct X log (41.31 KB, text/plain)
2006-09-01 22:27 UTC, Martijn van de Streek
no flags Details
xorg.conf used to create previous log (4.36 KB, text/plain)
2006-09-01 22:28 UTC, Martijn van de Streek
no flags Details
X log file when using old patch (52.50 KB, text/plain)
2006-09-01 22:40 UTC, Martijn van de Streek
no flags Details
log with the first working patch (63.67 KB, text/plain)
2006-09-03 14:13 UTC, Erik Andren
no flags Details
current git (with newer patch already applied) non working log. (34.68 KB, text/plain)
2006-09-03 14:14 UTC, Erik Andren
no flags Details
New patch to fix BIOS parsing problem (5.54 KB, patch)
2006-10-13 14:55 UTC, henry.zhao@oracle.com
no flags Details | Splinter Review
attempted fix from other bug for ATOM bios parsing.. (1.80 KB, patch)
2006-11-15 00:56 UTC, Dave Airlie
no flags Details | Splinter Review
Xorg log using the "guesswork 101" patch (54.67 KB, text/plain)
2007-01-24 15:18 UTC, Tormod Volden
no flags Details
Xorg log from latest git + patch 7409 (53.70 KB, text/plain)
2007-02-09 14:41 UTC, Tormod Volden
no flags Details
Xorg log from latest git without patch (53.30 KB, text/plain)
2007-02-09 14:42 UTC, Tormod Volden
no flags Details
Revamped patch 7409 for current git (5.56 KB, patch)
2007-02-09 14:48 UTC, Tormod Volden
no flags Details | Splinter Review
Xorg log from latest git + patch 7409 + patch 7793 (52.21 KB, text/plain)
2007-02-10 16:16 UTC, Tormod Volden
no flags Details
Patch modified for the latest source structure (5.85 KB, patch)
2007-02-15 17:14 UTC, henry.zhao@oracle.com
no flags Details | Splinter Review
Xorg log from latest git with modified patch 8746 (48.59 KB, text/plain)
2007-02-16 14:39 UTC, Tormod Volden
no flags Details
Xorg.0.log from Dominik in Ubuntu bug #22985 (51.92 KB, text/plain)
2007-05-28 01:41 UTC, Tormod Volden
no flags Details
log from failing 6.7.191 (31.46 KB, text/plain)
2007-08-23 12:07 UTC, Tormod Volden
no flags Details
log from successful run (56.66 KB, text/plain)
2007-08-23 16:44 UTC, Tormod Volden
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas George 2006-01-02 03:00:03 UTC
I just built X.org 7.0 on an Acer Ferrari 4005 running Debian AMD64. The
-configure detected the video card (a Radeon Mobility X700 on PCI express), but
after that the screen stays blank. A xev from the network shows mouse and
keyboard events, and Ctrl-Meta-Backspace kills the server, so it is mostly fine,
but the screen is completely blank (not black, off).

On the same system, with Debian X.org 6.8, the fglrx driver works... let's just
say it works, and the vesa driver works in some extents.

Apart from the straightforward parts, the detected xorg.conf shows:

Section "Device"
        #<snip comments of available driver options>
        Identifier  "Card0"
        Driver      "ati"
        VendorName  "ATI Technologies Inc"
        BoardName   "Radeon Mobility X700 (PCIE)"
        BusID       "PCI:1:0:0"
EndSection

The corresponding lspci output is:

0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility
X700 (PCIE) (prog-if 00 [VGA])
        Subsystem: Acer Incorporated [ALI]: Unknown device 007e
        Flags: bus master, fast devsel, latency 0, IRQ 209
        Memory at c8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at 9000 [size=256]
        Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at c0120000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] #10 [0001]
        Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
0000:01:00.0 0300: 1002:5653
        Subsystem: 1025:007e

I'll attach the full server log in a comment.

Regards,

-- 
  Nicolas George
Comment 1 Nicolas George 2006-01-02 03:01:39 UTC
Created attachment 4209 [details]
server log
Comment 2 Alan Coopersmith 2006-01-03 07:14:27 UTC
The Acer Ferrari 4005 has too many outputs and confuses the screen detection.
You have to tell it to try the LVDS first to get the LCD panel to come up - in
the ATI driver section in your xorg.conf set MonitorLayout to "LVDS, NONE".
Comment 3 Nicolas George 2006-01-03 10:12:33 UTC
Thank you, that did the trick.

Now that I know what to look for, the problem is obvious in the log, but in the
tens of lines, I did not remark it at all. Was there any document I should have
read before posting here, and that would have set me on the track?

Regards, and happy new year,

-- 
  Nicolas George
Comment 4 Alan Coopersmith 2006-01-03 10:44:38 UTC
The only documentation is the various mailing list and web forums where this
has come up before.   I know mainly because I've had to use this on my Ferrari
4005.   I'm re-opening this bug, because I think it's a bug that you have to
do this and that the detection built into the driver fails to detect the panel
if you don't.
Comment 5 C. Dominik Bodi 2006-03-18 08:06:27 UTC
I can confirm this bug. I have a Targa Traveller 826 laptop, it's got a Mobility
Radeon X700 chipset. It's got two additional outputs, VGA and S-video. Without
the MonitorLayout workaround X gets started on the VGA output, even when no
monitor is connected to it. Let me know if you need more information, like
logfiles etc.

Atm, this prevents me from installing fedora core 5 test 3, the console-based
installer is horribly broken.

Regards,
Dominik
Comment 6 henry.zhao@oracle.com 2006-06-08 22:07:52 UTC
<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.

Comment 7 henry.zhao@oracle.com 2006-06-08 22:17:31 UTC
Created attachment 5858 [details] [review]
Fixes to improve monitor type detection and monitor probing for radeon driver
Comment 8 Erik Andren 2006-06-17 02:39:45 UTC
Henry, I took your patch and applied to to my git tree (some minor tweaking were
needed). 

On my system (Dell C640, Radeon Mobility 7500 laptop) this is the first time
that CRT2 sucessfully detects an external monitor, meaning that I don't need to
add any 
manual hsync and vsync modes in my xorg.conf. 

I'm posting your patch modified by me and my xorg.log before and after applying
it to current xf86-video-ati.git

Comment 9 Erik Andren 2006-06-17 02:41:33 UTC
Created attachment 5950 [details] [review]
The "gitified" patch
Comment 10 Erik Andren 2006-06-17 02:42:20 UTC
Created attachment 5951 [details]
Xorg log without the patch applied
Comment 11 Erik Andren 2006-06-17 02:42:52 UTC
Created attachment 5952 [details]
Xorg log with the patch applied
Comment 12 Michel Dänzer 2006-06-17 02:56:36 UTC
Won't this break when VBE isn't available?
Comment 13 Erik Andren 2006-06-17 12:54:07 UTC
(In reply to comment #12)
> Won't this break when VBE isn't available?

I removed my libvbe.so and got the same result as before applying the patch so
it didn't break anything for me atleast. 
Comment 14 Michel Dänzer 2006-06-18 04:44:44 UTC
Okay, I thought it called VBE functions unconditionally, but I mislooked.

I'm not into the display management enough to say yay/nay, but there's an
unrelated RN50 specific max_pll_freq change in there.
Comment 15 henry.zhao@oracle.com 2006-06-18 18:21:21 UTC
Change of max_pll_freq is not relevant. I also have some other changes, will post
a revision shortly.
Comment 16 henry.zhao@oracle.com 2006-06-22 17:38:14 UTC
Created attachment 6026 [details] [review]
Revision to fixes to improve monitor type detection and monitor probing for radeon driver
Comment 17 henry.zhao@oracle.com 2006-06-22 17:41:19 UTC
I am posting a revision of the patch - see the attached.  With this patch you
will see the following improvements - you will be able to

(1) Start X server without a config file, with or without CRT connected.

    * Without CRT, you will get a native LCD resolution 1680x1050.
    * With CRT connected, you will get a resolution that is the largest
      common mode supported by both LCD and CRT monitor, which could be
      lower than LCD's native resolution.

(2) Connect external CRT to a system previously booted without external
    CRT connected.

    If you first boot machine without CRT connected, later decide to
    connect CRT - you can do it without rebooting, only a server restart
    will turn on display of the CRT monitor.

Featrue (2) is added in this revision:

When a laptop is booted without CRT connected, BIOS powers down DAC
of VGA port to save power. This results in

    * Wrong resutls from CRT connection testing
      (RADEONCrtIsPhysicallyConnected()) because testing needs to
      read/write DAC registers.
    * Failure in connecting external CRT later, there is no or very dim display
      on monitor screen.

    The new patch solves the problem by following this sequence:

    * If DAC is detected powered down, power it up before doing
      CRT connection testing.
    * If testing result shows CRT is connected, keep DAC power up,
      otherwise power DAC down again.
i
Comment 18 Erik Andren 2006-07-06 05:08:30 UTC
Henry, I just wanted to report that your new patch is working wonderfully on my
machine.
Comment 19 Erik Andren 2006-08-27 07:48:30 UTC
(In reply to comment #18)
> Henry, I just wanted to report that your new patch is working wonderfully on my
> machine.

Seems like I replied to fast: The first patch posted by Henry Zhao works fine,
the second one doesn't :/
Comment 20 henry.zhao@oracle.com 2006-08-28 00:07:42 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > Henry, I just wanted to report that your new patch is working wonderfully on my
> > machine.
> 
> Seems like I replied to fast: The first patch posted by Henry Zhao works fine,
> the second one doesn't :/

Please give more details: 

(1) On what system did you test both patches ?  
(2) What did you see when applying the second path ?
(3) Please also send both log files when applying these patches.
Comment 21 Martijn van de Streek 2006-08-31 22:23:41 UTC
Created attachment 6774 [details]
Xorg.0.log with patch from latest git (X700 / HP NW8240 laptop)

X startup breaks when I apply this patch. I never get a graphical screen, and
Ctrl+Alt+BS doesn't kill the server. Ctrl+Alt+F1 does, and gives the error
found at the bottom of the log.
Comment 22 Martijn van de Streek 2006-08-31 22:24:49 UTC
I also think this bug _might_ be related in some ways to bug #8038 in some way.
Comment 23 henry.zhao@oracle.com 2006-09-01 11:34:42 UTC
(In reply to comment #21)
> Created an attachment (id=6774) [edit]
> Xorg.0.log with patch from latest git (X700 / HP NW8240 laptop)
> 
> X startup breaks when I apply this patch. I never get a graphical screen, and
> Ctrl+Alt+BS doesn't kill the server. Ctrl+Alt+F1 does, and gives the error
> found at the bottom of the log.

I found this message in your log file:

(WW) RADEON(0): Invalid Monitor type specified for 2nd port
(**) RADEON(0): MonitorLayout Option:
        Monitor1--Type LVDS, Monitor2--Type ??H^

What did you actually specify for Monitor2's type ?

It is weired that the same probing data is generated for port 1 and port 2.

Please:

(1) Try without a config file, or specify correct monitor type for port 2 in
    the config file.
(2) Send log file when the first patch is used (according what you said, the
    display was correct).

Thanks. 
Comment 24 Martijn van de Streek 2006-09-01 22:27:57 UTC
Created attachment 6791 [details]
Correct X log

I must have uploaded the wrong file. Here's the correct one, made with a very
basic config file (next attachment)
Comment 25 Martijn van de Streek 2006-09-01 22:28:29 UTC
Created attachment 6792 [details]
xorg.conf used to create previous log
Comment 26 Martijn van de Streek 2006-09-01 22:31:09 UTC
(In reply to comment #24)
> Created an attachment (id=6791) [edit]
> Correct X log
> 
> I must have uploaded the wrong file. Here's the correct one, made with a very
> basic config file (next attachment)

btw, I had no external monitor connected when I ran this (but I do have lots of
options.. DVI, VGA, S-Video, at least)
Comment 27 Martijn van de Streek 2006-09-01 22:40:11 UTC
Created attachment 6793 [details]
X log file when using old patch

The 'older' patch seems to work (I get a 1920x1200 image on my laptop LCD).
This is the Xorg.0.log for a 'working' run with that patch.

It's still suffering from bug #8038 though.
Comment 28 Erik Andren 2006-09-03 14:12:21 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > Henry, I just wanted to report that your new patch is working wonderfully
on my
> > > machine.
> > 
> > Seems like I replied to fast: The first patch posted by Henry Zhao works fine,
> > the second one doesn't :/
> 
> Please give more details: 
> 
> (1) On what system did you test both patches ?  
A Dell latitude C640 using a radeon mobility 7500 32 MB card.

> (2) What did you see when applying the second path ?
Nothing, X crashes and drops a stack dump.

> (3) Please also send both log files when applying these patches.


Comment 29 Erik Andren 2006-09-03 14:13:46 UTC
Created attachment 6803 [details]
log with the first working patch
Comment 30 Erik Andren 2006-09-03 14:14:42 UTC
Created attachment 6804 [details]
current git (with newer patch already applied) non working log.
Comment 31 Dave Airlie 2006-10-03 23:39:24 UTC
This looks mostly to be caused by bad BIOS parsing code from ATI..

fglrx shows the BIOS connector info differently than radeon does, perhaps Sun
can find out from ATI what exactly has changed in the BIOS layouts....
Comment 32 henry.zhao@oracle.com 2006-10-13 14:55:19 UTC
Created attachment 7409 [details] [review]
New patch to fix BIOS parsing problem

Yes, the problem is BIOS returns incorrect DDCType for both ports even when
RADEONGetConnectorInfoFromBIOS() returns true. I saw several reports that
the first patch works, but not the second. The difference between the
first patch and second patch that accounts for this is 

In first patch, even when RADEONGetConnectorInfoFromBIOS() returns true, the 
default setting is used for both ports when DDCType is detected 0 on port 0.
But in second patch, when DDCType is detected 0 on BOTH ports (port 0 and 
port 1).

In the case reported by Eric, 

(1) When the first patch is used. On port 0, default setting sets DDC_DVI to 
    DDCType, DDC2 probing fails but VBE probing succeeds for the LCD monitor.
    On port 1, defaut setting sets DDC_VGA to DDCType, DDC2 probing succeeds.
(2) When the second patch is used. On port 0, since defautl setting is not
    used, DDCType is 0, DDC2 probing does not even happen, VBE probing does
    not happen either because test on CRT connection fails.
 
In case reported by martijn,

(1) When the first patch is used. On port 0, default setting sets DDC_DVI to 
    DDCType, DDC2 probing fails but VBE probing succeeds for the LCD monitor.
    On port 1, default setting sets DDC_VGA to DDCType, DDC2 probing fails,
    VBE probing does not happen because CRT is not connected.
(2) When the second patch is used. On port 0, since defautl setting is not
    used, DDCType is 0, DDC2 probing does not even happen, VBE probing does
    happen and succeeds for the LCD montior. On port 1, DDCType is incorrectly
    set to DDC_MONID, DDC2 probe mistakenly detects it LCD too.

In many laptop cases I saw, BIOS testing returns DDCType 0 for port 0, but
it does not necessarily returns DDCType 0 for port 1 (this is however true for 

ferrari series). In this patch I use DDCType of port 0 being 0 as a condition
to use default setting. However this patch may not solve all problems, in that
case a config file with MonitorLayout option will be required.
Comment 33 Dave Airlie 2006-10-14 00:12:32 UTC
The BIOS isn't reported incorrectly the RADEON ATOM BIOS parser is just not so
good, I'm trying to collect enough information to see if I can fix the ATOM
parser to actually DTRT instead of hacking around it using VBE DDC which in the
end is just using the BIOS to do something that the ATI driver can do itself if
it can understand the BIOS tables...
Comment 34 henry.zhao@oracle.com 2006-11-07 19:00:21 UTC
(In reply to comment #33)
> The BIOS isn't reported incorrectly the RADEON ATOM BIOS parser is just not so
> good, I'm trying to collect enough information to see if I can fix the ATOM
> parser to actually DTRT instead of hacking around it using VBE DDC which in the
> end is just using the BIOS to do something that the ATI driver can do itself if
> it can understand the BIOS tables...

Hopefully the parser can be fixed to correctly detect Type information - DDCType
in particular. Hacking VBE DDC happens only when DDC2 probing fails and no DDC
is available. This helps in these situations: a lot of laptops do not support 
DDC2 probing, using VBE DDC can help get EDID data; some CRT monitor do not
support DDC2, but support VBE DDC.
Comment 35 Dave Airlie 2006-11-15 00:54:07 UTC
*** Bug 7559 has been marked as a duplicate of this bug. ***
Comment 36 Dave Airlie 2006-11-15 00:56:28 UTC
Created attachment 7793 [details] [review]
attempted fix from other bug for ATOM bios parsing..

this is just an attempt at fixing the ATOM BIOS parser to maybe dtrt... it is
guesswork 101...
Comment 37 Paul Lauria 2007-01-09 11:50:12 UTC
(In reply to comment #36)
> Created an attachment (id=7793) [edit]
> attempted fix from other bug for ATOM bios parsing..
> 
> this is just an attempt at fixing the ATOM BIOS parser to maybe dtrt... it is
> guesswork 101...

Anything on this front, Dave? This really sucks for those of us with X700s as it
makes it extremely difficult to install any distro... has it been fixed for 7.2?
Comment 38 Tormod Volden 2007-01-24 15:18:29 UTC
Created attachment 8497 [details]
Xorg log using the "guesswork 101" patch

I applied Dave's "guesswork 101" patch 7793 to the Ubuntu version xserver-xorg-video-ati 6.6.2-0ubuntu5. It did not help on my X700/laptop, I still have to use the MonitorLayout setting.
Comment 39 Timo Jyrinki 2007-02-01 11:58:25 UTC
This bug actually deserves the "major" severity quite well, as it seems to affect quite many users. There are currently 19 duplicates on this bug in ubuntu's bugzilla. Giving the URL in case more logs or something need to be searched: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/22985
(duplicates are listed in the left pane, a page or two down from the top, under "Duplicates of this bug").
Comment 40 henry.zhao@oracle.com 2007-02-07 19:24:38 UTC
(In reply to comment #39)
> This bug actually deserves the "major" severity quite well, as it seems to
> affect quite many users. There are currently 19 duplicates on this bug in
> ubuntu's bugzilla. Giving the URL in case more logs or something need to be
> searched:
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/22985
> (duplicates are listed in the left pane, a page or two down from the top, under
> "Duplicates of this bug").
> 

(In reply to comment #39)
> This bug actually deserves the "major" severity quite well, as it seems to
> affect quite many users. There are currently 19 duplicates on this bug in
> ubuntu's bugzilla. Giving the URL in case more logs or something need to be
> searched:
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/22985
> (duplicates are listed in the left pane, a page or two down from the top, under
> "Duplicates of this bug").
> 

(In reply to comment #39)
> This bug actually deserves the "major" severity quite well, as it seems to
> affect quite many users. There are currently 19 duplicates on this bug in
> ubuntu's bugzilla. Giving the URL in case more logs or something need to be
> searched:
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/22985
> (duplicates are listed in the left pane, a page or two down from the top, under
> "Duplicates of this bug").
> 

Can you try the patch (attachment 7409 [details] [review]) to see if it works.
Comment 41 Tormod Volden 2007-02-09 14:41:13 UTC
Created attachment 8649 [details]
Xorg log from latest git + patch 7409

I applied the 7409 patch to git from yesterday, testing on my Acer TravelMate 8100  with X700 Mobility PCI-E. The screen is still black.
Comment 42 Tormod Volden 2007-02-09 14:42:17 UTC
Created attachment 8650 [details]
Xorg log from latest git without patch
Comment 43 Tormod Volden 2007-02-09 14:48:33 UTC
Created attachment 8651 [details] [review]
Revamped patch 7409 for current git

The patch 7409 would not apply cleanly nor build. I had to replace a bunch of "." member operators to "->" pointers. Here is the final patch that I used.
Comment 44 Tormod Volden 2007-02-09 15:15:10 UTC
Maybe I should add that, except from the ati driver and libdrm2 2.3.0-1 and kernel 2.6.20-6-generic I use the plain Ubuntu 6.10 setup with xorg 7.1.

Compared to the original 6.6.2-0ubuntu4, or my recompiled 6.6.3-2 from debian, yesterday's git version has some weirdness (with or without the patch): At start or stop or console-switching it goes black for around 15 seconds.
Comment 45 Tormod Volden 2007-02-10 16:16:58 UTC
Created attachment 8656 [details]
Xorg log from latest git + patch 7409 + patch 7793

I tried applying Dave's "guesswork" 7793 patch in addition to Henry's patch 7409.
Comment 46 henry.zhao@oracle.com 2007-02-15 17:14:52 UTC
Created attachment 8746 [details] [review]
Patch modified for the latest source structure

Tormod,

Patch 7409 was created in October 2006, when we had definition

radeon_probe.h:    RADEONConnector PortInfo[2];

Now the source has changed such definition to

radeon_probe.h:    RADEONConnector *PortInfo[RADEON_MAX_CONNECTOR];

This is why you had to revamp it to make it work. Thank you for the effort.
However in patch 8651, lines having (port == &pRADEONEnt->PortInfo[0]) didn't
get changed to (port == pRADEONEnt->PortInfo[0]). This patch corrects this 
(with very minior changes). Please try it (alone) and let me know.
Comment 47 Tormod Volden 2007-02-16 14:39:09 UTC
Created attachment 8758 [details]
Xorg log from latest git with modified patch 8746

Holy cow, it works! Thank you so much! Would it be possible to apply this fix to the stable 6.6.3 release (for Xorg 7.2)?
Comment 48 Dave Airlie 2007-02-16 14:43:26 UTC
As  I said this is a hack, it doesn't actually fix the problem....

To fix the problem we need to fix the ATOM bios parsing.. 

I've started looking at this a few times but it's a real pain in the ass, I'm hoping to maybe fix it up as part of the randr 1.2 work...
Comment 49 Daniel Stone 2007-02-27 01:29:39 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 50 Timo Jyrinki 2007-03-08 23:36:34 UTC
On the Ubuntu side of things (see the links a bit above), the workaround patch was applied on top of 6.6.3 in the development version. It seems to work for many, but so far it also seems at least two people are now having problems after the patch. The problem was a huge one (19 duplicates), so I guess at some point it has to be evaluated whether there are enough new problems to have the patch reverted, or if the patch really fixed _so_ many computers that those new ones can be (sadly) ignored until a real solution is found.

In the last 2-3 comments, there is currently mentioned one HP nw8240 FireGL V5000 user (not the later comment where someone else had tested an older daily CD) with a new blank screen problem, and one (no details) X700 user that already had a screen corruption problem when going to a console, but also now wrong resolution and offset after the update.

Considering the patch was already named to be a hack, this is of course not that surprising, but just FYI.
Comment 51 henry.zhao@oracle.com 2007-03-09 12:36:20 UTC
(In reply to comment #50)
> On the Ubuntu side of things (see the links a bit above), the workaround patch
> was applied on top of 6.6.3 in the development version. It seems to work for
> many, but so far it also seems at least two people are now having problems
> after the patch. The problem was a huge one (19 duplicates), so I guess at some
> point it has to be evaluated whether there are enough new problems to have the
> patch reverted, or if the patch really fixed _so_ many computers that those new
> ones can be (sadly) ignored until a real solution is found.
> 
> In the last 2-3 comments, there is currently mentioned one HP nw8240 FireGL
> V5000 user (not the later comment where someone else had tested an older daily
> CD) with a new blank screen problem, and one (no details) X700 user that
> already had a screen corruption problem when going to a console, but also now
> wrong resolution and offset after the update.
> 
> Considering the patch was already named to be a hack, this is of course not
> that surprising, but just FYI.
> 

Can you send more info on the new problems after the patch.
Comment 52 Timo Jyrinki 2007-03-15 13:07:52 UTC
(In reply to comment #51)
> Can you send more info on the new problems after the patch.

A big majority has given success reports, ie. the patch has fixed their issues, but there are two expections. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/90571 - this one has a blank screen on HP nw8240 with ATI FireGL V5000 PCIE after the update unless manually specifying monitor refresh rates. The other one is reporting that the update created a wrong resolution/offset situation: http://librarian.launchpad.net/6710130/ati-X700-lastupgrade.jpg. That's all the information at the moment.
Comment 53 henry.zhao@oracle.com 2007-03-15 16:22:37 UTC
(In reply to comment #52)
> (In reply to comment #51)
> > Can you send more info on the new problems after the patch.
> 
> A big majority has given success reports, ie. the patch has fixed their issues,
> but there are two expections.
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/90571 -
> this one has a blank screen on HP nw8240 with ATI FireGL V5000 PCIE after the
> update unless manually specifying monitor refresh rates. 

I checked the log file for the above problem, and found out that you were
probably using patch 8651. Please try the later version 8746.

The other one
> reporting that the update created a wrong resolution/offset situation:
> http://librarian.launchpad.net/6710130/ati-X700-lastupgrade.jpg. That's all the
> information at the moment.

Where can I find a log file for above problem ?
Comment 54 Timo Jyrinki 2007-03-17 10:30:25 UTC
(In reply to comment #53)
> I checked the log file for the above problem, and found out that you were
> probably using patch 8651. Please try the later version 8746.

Well, it's not 8651 and it's not 8746 either. The actual patch that went in is this: http://librarian.launchpad.net/6456764/13_fdo_att7409_bug5473.diff, and I'm now trying to ask the author if it really was based on 7409 like it's named (with which he earlier said he still had blank screen, but claims that this patch at launchpad is such that it works for him). Are you able to say if it's clearly "just" 7409/8651 with additional modifications, or if it is a 8746 modified for the 6.6.3 driver, or something in-between? It adds extra complexity that it has to be backported.

> Where can I find a log file for above problem ?

Unfortunately the user has not given logs, only comment in the https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/22985 which is the long, long bug that has all the duplicates related to this problem. Near the end there is this attachment "wrong offset/resolution", and also after that there are a few success reports from people that the current patch already helped.
Comment 55 Tormod Volden 2007-03-25 14:25:05 UTC
Timo, when I had said once that 7409 didn't help, it was because I had tried to apply it (or my not-so-perfectly revamped 8651) to current git at that time (that would rather need the cleanly revamped 8746). Later I tried to apply 7409 to Ubuntu Edgy (ati 6.6.2) and here it worked, with "cosmetic" adjustments to the patch.

Henry, I don't think Luka was using 8651, because it never made it to a published Ubuntu package. He most probably used 1:6.6.3-2ubuntu3 which includes the adjusted 7409.
Comment 56 Kyle Pablo 2007-04-01 16:32:34 UTC
Hello,

I am having a simular problem with the radeon driver on the Acer Ferrari 4005.  I get a blank screen when I logout, not on bootup.  I filed a bug report not seeing this bug report so maybe you guys could help me out.  The report I filed is here--->https://bugs.freedesktop.org/show_bug.cgi?id=10194

Comment 57 caglar 2007-04-04 13:31:22 UTC
What's the status of this bug? We have similar bug reports against xf86-video-ati-6.6.3 also.
Comment 58 Kyle Pablo 2007-04-10 14:08:29 UTC
hello,

could it be that the mapping of the screens is backwards?  I am on the latest version of FC6.  I found this info in---->http://lists.freedesktop.org/archives/xorg/2006-February/012808.html
Comment 59 Tormod Volden 2007-05-28 01:41:48 UTC
Created attachment 10099 [details]
Xorg.0.log from Dominik in Ubuntu bug #22985

Another Ubuntu user, using 6.6.3-2ubuntu3 which includes patch 7409, gets a VBE error and black screen:
(II) RADEON(0): VESA VBE DDC supported
(II) RADEON(0): VESA VBE DDC Level 2
(II) RADEON(0): VESA VBE DDC transfer in appr. 1 sec.
(II) RADEON(0): VESA VBE DDC unkown failure 768
(II) RADEON(0): DDC Type: 0, Detected Type: 0

Can this be related to the patch, or is it a completely separate issue?
Comment 60 Tormod Volden 2007-08-23 12:07:08 UTC
Created attachment 11243 [details]
log from failing 6.7.191

With 6.6.193 I still need the patch from attachment 8746 [details] [review] to get my X700 working. Without the patch, the screen stays black even when I switch to a console.

For 6.7.191, this patch does not apply, and the server does not even start. I tried adding the "MonitorLayout" option to the "Device" section, but it did not help.
Comment 61 Alex Deucher 2007-08-23 15:53:25 UTC
(In reply to comment #60)

> For 6.7.191, this patch does not apply, and the server does not even start. I
> tried adding the "MonitorLayout" option to the "Device" section, but it did not
> help.
> 

try ati git master. no patches.
Comment 62 Tormod Volden 2007-08-23 16:44:00 UTC
Created attachment 11246 [details]
log from successful run

I took xserver-xorg-video-ati 6.7.191-1ubuntu1, applied the "Always assume LVDS is connected" patch to it, and ran it with xserver-xorg-core 1.3.0.0.dfsg-6ubuntu3feisty1. Works fine! Thanks!
Comment 63 Alex Deucher 2007-08-31 07:16:50 UTC
this should be resolved in ati git master and driver releases 6.7.192 and up.
Comment 64 Carsten Einig 2007-10-30 04:16:16 UTC
Hi,

now I use Xorg 7.3 and the bug is still there.

After adding Option "MonitorLayout" "LVDS,AUTO" do the Device section of xorg.conf and a x-server reboot, it works.

XMODULE="ati"
XBOARDNAME="ATI Technologies Inc Radeon Mobility X700 (PCIE)"
XBUSID="PCI:1:0:0"
XVENDOR="1002"
XDEVICE="5653"


Regards,
Carsten
Comment 65 Carsten Einig 2007-10-30 04:54:03 UTC
the bug is now fixed in xserver-xorg-video-ati 6.7.195


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.