Created attachment 4209 [details]
server log

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".

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

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.

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

<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.

Created attachment 5858 [details] [review]
Fixes to improve monitor type detection and monitor probing for radeon driver

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

Created attachment 5950 [details] [review]
The "gitified" patch

Created attachment 5951 [details]
Xorg log without the patch applied

Created attachment 5952 [details]
Xorg log with the patch applied

Won't this break when VBE isn't available?

(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. 

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.

Change of max_pll_freq is not relevant. I also have some other changes, will post
a revision shortly.

Created attachment 6026 [details] [review]
Revision to fixes to improve monitor type detection and monitor probing for radeon driver

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

Henry, I just wanted to report that your new patch is working wonderfully on my
machine.

(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 :/

(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.

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.

I also think this bug _might_ be related in some ways to bug #8038 in some way.

(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. 

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)

Created attachment 6792 [details]
xorg.conf used to create previous log

(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)

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.

(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.

Created attachment 6803 [details]
log with the first working patch

Created attachment 6804 [details]
current git (with newer patch already applied) non working log.

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....

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.

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...

(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.

*** Bug 7559 has been marked as a duplicate of this bug. ***

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...

(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?

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.

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").
> 

(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.

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.

Created attachment 8650 [details]
Xorg log from latest git without patch

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.

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.

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.

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.

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)?

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...

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

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.

(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.

(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.

(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 ?

(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.

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.

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

What's the status of this bug? We have similar bug reports against xf86-video-ati-6.6.3 also.

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

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?

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.

(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.

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!

this should be resolved in ati git master and driver releases 6.7.192 and up.

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

the bug is now fixed in xserver-xorg-video-ati 6.7.195