Red Hat Bugzilla – Bug 194322
s-c-d generates a non-working dual head configuration for ATI device
Last modified: 2009-07-14 12:47:28 EDT
The configuration file generated for a dual head ATI is incorrect to the extent
that the system does not drive the secondary display with generated xorg.conf
file but a manually generated xorg.conf file does drive the secondary monitor.
Both are attached.
This behavior occurs with system-config-display-1.0.37-2
The problem was produced using an ATI Technologies Inc Radeon RV200 LX [Mobility
FireGL 7800 M7] chipset on an IBM Thinkpad A31p laptop. However, given the many
fedora-list messages (among others) on this topic the problem should occur with
most any nvidia or ati based system.
To reproduce the problem, start with a default, working single head
configuration. Use s-c-d to select the use of dual head. Select spanning
desktops for a Desktop layout. After logging out, GDM displays the login screen
on the primary monitor and the secondary monitor does not display anything. On
the system being tested, the secondary monitor power led blinks green to
indicate the absence of signal. Next, log in. The system acts as if dual head
is active (indicated by selecting s-c-d from the main menu and noting that
one-half of the root password dialog is displayed on the right side of the
primary monitor.) Also, the X log file (attached) indicates that the secondary
monitor was not detected.
It should also be noted that an xorg bug introduced with FC5 broke dual head
support on nvidia and ati drivers. This bug is now fixed in Rawhide, FWIW.
Also, s-c-d worked fine with FC4 so one might argue that the ati/nvidia drivers
might not be doing the right thing in response to a given xorg.conf.
Created attachment 130665 [details]
A tarball containing working and non-working configuration files, associated Xorg logs and a README file.
Created attachment 173641 [details]
untarred README from the tarball
Created attachment 173661 [details]
untarred broken Xorg.0.log from the tarball
Created attachment 173781 [details]
untarred working Xorg.0.log from the tarball
Created attachment 173801 [details]
untarred file from the tarball
Created attachment 173841 [details]
untarred file from the tarball
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
First off, the form does not offer me the ability to change the status. Don't
you just hate that? I certainly do.
Second, I installed KDE Live Fedora 9 Beta, then did an update as of this
morning and retested. With two external monitors attached to my laptop, s-c-d
does absolutely nothing when I click on OK in the DUAL-HEAD tab after
configuring my Samsung Syncmaster 245 monitor. I'm guessing that there might be
logs with results somewhere but this looks like pretty clear wrong behavior.
I'll look forward to the next response, which I'm expecting sometime in 2010
when this bug goes through the "maybe the problem went away" cycle one more time.
One more thing. The device is now a nvidia device, no longer an ATI, but I
suspect it should not matter.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.