Bug 131489 - xorg fails to support multiple screens with ATI M10
xorg fails to support multiple screens with ATI M10
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-01 14:21 EDT by Douglas Furlong
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-06 16:13:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log file (30.71 KB, text/plain)
2004-11-27 19:08 EST, Douglas Furlong
no flags Details
Xorg.0.log (31.94 KB, application/octet-stream)
2004-12-04 06:38 EST, Douglas Furlong
no flags Details
xorg.conf (3.75 KB, application/octet-stream)
2004-12-04 06:39 EST, Douglas Furlong
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 1559 None None None Never

  None (edit)
Description Douglas Furlong 2004-09-01 14:21:13 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
I am attempting to set up a second monitor on my Targa Visionary,
which has the ATI Radeon Mobility 9600 M10 graphics adapter.

I am able to get the primary display to be shown on my monitor,
however it is limited to 1024*768, no matter what variation of
resolutions I try to use. I have got it working at 1600*1200 once, but
I have no idea how I managed this and have upgraded xorg since.
1600*1200 is the maximum resolutoin in windows as well, even though
the card should be capable of more.

When looking in the X11 log files I noticed this entry which I think
may be pertinent.
(WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone
mode disabled

The second monitor I am using is the Sony GDM-F500, and it does not
support DDC.

I will attach the log and conf file shortly.

Please let me know if I can provide any trouble shooting for this.


Version-Release number of selected component (if applicable):
xorg-x11-6.7.99.903-1

How reproducible:
Always

Steps to Reproduce:
1. Configure X to work with mutiple monitors.
2.
3.
    

Actual Results:  Display on single monitor with a maximum resolution
of 1024*768.

Expected Results:  See a display on multiple monitors, with defined
resolutions.

Additional info:
Comment 1 Douglas Furlong 2004-10-31 16:24:05 EST
I am still having this problem.

I think it may be related to my external monitor not providing DDC
information.

Is there any thing that I can do to help track down this bug, and help
test the solutions.
Comment 2 Douglas Furlong 2004-11-27 19:08:11 EST
Created attachment 107506 [details]
Log file

This is the current log file for when X starts.
Comment 3 Mike A. Harris 2004-12-03 23:25:25 EST
If the display does not support DDC, then X and other tools
can not autodetect the display.  In these cases, you must manually
configure the display type, either by picking it from a list, or
by hand editing the config file.

Please upgrade to Fedora Core 3 final release, and apply all
xorg-x11 and kernel updates that have since been released for
FC3.  If your panel is not manually selectable from the list
supplied in our config tool, please open a new bug against the
"hwdata" component, requesting the display be added to the
database.  In order to do that, we'll need you to attach the
Windows .INF file for your monitor to the bug report, which
is usually on a CD or floppy that comes with the display, or
available from the manufacturer's website.

Please indicate if this resolves the problem for you or not.

Thanks in advance.
Comment 4 Douglas Furlong 2004-12-04 06:36:25 EST
As of Sat 4th Dec 11:33am GMT I am fully up to date running FC3.

My monitor has always been on the list of known devices, so I have
always been able to select it from a drop down list, that has not been
the problem.

The problem is that this appears to be ignored, as in the Xorg.0.log
file, it suggests that it is search for DDC information and when it
can't find it, it ignores part of the information in the xorg.conf file.

I have attached my laptop to a monitor that does support DDC and I was
able to get a higher resolution on the external monitor, so I do
beleive this is related to this monitor not supporting DDC.

I have attached both my configuration file and log file.

Please let me know if I can provide you with any more assistance.
Comment 5 Douglas Furlong 2004-12-04 06:38:12 EST
Created attachment 107891 [details]
Xorg.0.log

Updated log file for running the below version of xorg-x11
xorg-x11-6.8.1-12.FC3.21
Comment 6 Douglas Furlong 2004-12-04 06:39:28 EST
Created attachment 107892 [details]
xorg.conf

Updated xorg.conf file while running the below versoin.
xorg-x11-6.8.1-12.FC3.21
system-config-display-1.0.24-1
Comment 7 Douglas Furlong 2005-01-02 12:44:15 EST
With some more searching I found the below bug over at freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=1559

After adding the Option "ScreenLayout" "LCD, CRT" to the xorg.conf file I was
able to get my screen working properly.

I am running the Text version of xorg wich I believe has the pactches mentioned
in this bug.

Is there any way of adding information to the xorg.conf file when
system-config-display fails to pick up DDC information?

I do not beleive I need the CRT2Hsyc etc, to get this working, just the
ScreenLayout option.

Any way, let me know if you want any more information, or if you consider this
not to be a bug.

Doug
Comment 8 Mike A. Harris 2005-12-01 16:55:53 EST
If you have to use the MonitorLayout directive, then you have to add it
manually.  If there was a way of detecting when you need to use MonitorLayout
or not, then there would be a way of autodetecting it period, and there
would be no reason to use MonitorLayout as the driver itself could just
autodetect it properly and do it.

So, in short - no, we can't put MonitorLayout in the config file automatically
and solve this problem, since the purpose of the directive is to manually
specify configurations in which can not be autodetected currently.

Technically, it is either:

1) A driver bug.

or

2) A limitation with no automatic solution.

Either way though, it is a general distribution non-specific issue so we
will track it in X.Org bugzilla from now on.
Comment 9 Douglas Furlong 2005-12-06 13:22:58 EST
Hi Mike, thanks for your reponse, please see my comments below.

(In reply to comment #8)
> If you have to use the MonitorLayout directive, then you have to add it
> manually.  If there was a way of detecting when you need to use MonitorLayout
> or not, then there would be a way of autodetecting it period, and there
> would be no reason to use MonitorLayout as the driver itself could just
> autodetect it properly and do it.

Is this strictly true though? I got the impression that the MonitorLayout was
needed when the system could not autodetect the hardware, if that was the case,
could one not assume that if the user manually selects the Monitors/ Displays we
can assume that for one reason or another auto-detection has failed, and as such
we need to manually add things like MonitorLayout and the CRT2Hsync and
CRT2Vrefresh.

Though I admit, this would probably get quite messy with different graphics
cards/ drivers that may be used, as, at a guess they all use different
configuration directives.

But I would argue, that it IS possible to know when these directives are
required, any time auto-detection does not work.

> So, in short - no, we can't put MonitorLayout in the config file automatically
> and solve this problem, since the purpose of the directive is to manually
> specify configurations in which can not be autodetected currently.

Not to bang on or any thing, but if you ONLY deal with autodetection, then why
do you allow the user to specify the monitors and hardware (I can understand
resolution/colours)?

If again, if the user is selecting the hardware it's due to the auto-detection
not working as the user wants, either picking up the wrong hardware, or not
picking it up at all. So to some extent the configuration wizards already
support it. I'm just asking "can it go further".

> Technically, it is either:
> 
> 1) A driver bug.
> 
> or
> 
> 2) A limitation with no automatic solution.
> 
> Either way though, it is a general distribution non-specific issue so we
> will track it in X.Org bugzilla from now on.

I think what I'm asking for system-config-display to be improved, to allow for
greater control over some of the more advanced configuration settings, again I
know this could get messy due to the requirements to work with multiple graphics
cards, but personally I think it would be a good thing to offer that (you of
course may dissagree :p)

(I've re-opened this bug, just as I'm not sure what else I should do...)
Comment 10 Mike A. Harris 2005-12-06 16:13:49 EST
(In reply to comment #9)
> Hi Mike, thanks for your reponse, please see my comments below.
> 
> (In reply to comment #8)
> > If you have to use the MonitorLayout directive, then you have to add it
> > manually.  If there was a way of detecting when you need to use MonitorLayout
> > or not, then there would be a way of autodetecting it period, and there
> > would be no reason to use MonitorLayout as the driver itself could just
> > autodetect it properly and do it.
> 
> Is this strictly true though? I got the impression that the MonitorLayout was
> needed when the system could not autodetect the hardware,

That is a wrong impression.  It is /only/ required if your particular
setup does not work with the defaults.  The driver itself is always in the
best position to set the default, as it has much more detailed intimate
knowledge of the hardware in question.  If the driver gets things wrong,
or can't autodetect properly, or even just has bugs in its autodetection,
no config tool can do any better, since all that knowledge is in the
driver itself.


> if that was the case,
> could one not assume that if the user manually selects the Monitors/ Displays we
> can assume that for one reason or another auto-detection has failed, and as such
> we need to manually add things like MonitorLayout and the CRT2Hsync and
> CRT2Vrefresh.

That is an invalid assumption however, and even if it were correct, there
is know way to know what the values for those options should be.  If there
was a way to know, then again, there would only be one sane choice, and that
would be something that could be done "automatic", thus avoiding the
necessity to make it an option.  The driver could just automatically turn
that on as a default.

 
> Though I admit, this would probably get quite messy with different graphics
> cards/ drivers that may be used, as, at a guess they all use different
> configuration directives.
> 
> But I would argue, that it IS possible to know when these directives are
> required, any time auto-detection does not work.

Once your code is committed to X.Org CVS, the problem should be resolved.

> > Technically, it is either:
> > 
> > 1) A driver bug.
> > 
> > or
> > 
> > 2) A limitation with no automatic solution.
> > 
> > Either way though, it is a general distribution non-specific issue so we
> > will track it in X.Org bugzilla from now on.
> 
> I think what I'm asking for system-config-display to be improved, to allow for
> greater control over some of the more advanced configuration settings, again I
> know this could get messy due to the requirements to work with multiple graphics
> cards, but personally I think it would be a good thing to offer that (you of
> course may dissagree :p)

It is an intentional Red Hat decision that the system-config-display is
not loaded with a bunch of complex options that most users never need.
In particular, hardware specific bug workarounds and hacks are not part
of the system-config-display tool very much intentionally.  The tool is
intended to be a simple and minimal configuration tool for choosing a
default resolution and colour depth, and not much more than that.

 
> (I've re-opened this bug, just as I'm not sure what else I should do...)

The real "root" problem here, is the video driver.  The video driver could
do better autodetection than it does currently, however it is quite complex
code at this point, and not flawless.  This has to be fixed in the driver
itself, and that problem is being tracked in the upstream X.org bugzilla
now.  I'm putting this bug back into the UPSTREAM state, as that is where
we are tracking the problem now.  We will not be making Red Hat specific
bandaids over this problem.  The only acceptable fix, is one that is
integrated directly into X.Org and agreed upon by the developers working
on the upstream video driver.

This is not a configuration tool issue, and "xorg-x11" component is not
the config tool anyway.

If you would like to see this issue resolved faster, I strongly recommend
adding useful information to the upstream bug report to assist the developers
in fixing the driver.  The MonitorLayout directive itself seems to just
be a bandaid to work around limitations in the driver.  With your help,
hopefully the driver code can get cleaned up in time for X11R7 or 7.1,
and the MonitorLayout directive can simply be removed from the driver as
unnecessary.

Setting status to "UPSTREAM" as we are tracking this in X.Org bugzilla
from now on.

Note You need to log in before you can comment on or make changes to this bug.