Bug 131489
| Summary: | xorg fails to support multiple screens with ATI M10 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Douglas Furlong <bugzilla_rhn> | ||||||||
| Component: | xorg-x11 | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||||
| Status: | CLOSED UPSTREAM | QA Contact: | David Lawrence <dkl> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | rawhide | ||||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2005-12-06 21:13:49 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
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. Created attachment 107506 [details]
Log file
This is the current log file for when X starts.
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. 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. 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
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
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 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. 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...) (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. |
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: