Bug 134200 - system-config-display chokes seeing custom xorg.conf
Summary: system-config-display chokes seeing custom xorg.conf
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-display
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 132514
TreeView+ depends on / blocked
 
Reported: 2004-09-30 05:51 UTC by Alexei Podtelezhnikov
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-04-03 18:22:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
xorg.conf to choke on (2.88 KB, text/plain)
2004-09-30 06:09 UTC, Alexei Podtelezhnikov
no flags Details
symptoms (832 bytes, text/plain)
2004-09-30 06:12 UTC, Alexei Podtelezhnikov
no flags Details
xorg.conf using UseModes (2.88 KB, text/plain)
2004-09-30 07:12 UTC, Paul Nasrat
no flags Details

Description Alexei Podtelezhnikov 2004-09-30 05:51:14 UTC
From Bugzilla Helper: 
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2) (KHTML, like 
Gecko) 
 
Description of problem: 
My custom xorg.conf ensures the DELL-recommended refresh rate, which 
is lower than the default. It's attached and it works just fine. 
 
Rerunning system-config-display (just out of curiosity) resulted in 
the attached failure. I guess it just fails to parse my file 
properly, i.e. some python scripts are broken or something. 
 
If I remove xorg.conf, it works. 
 
 
Version-Release number of selected component (if applicable): 
system-config-display-1.0.17-2 
 
How reproducible: 
Always 
 
Steps to Reproduce: 
1. add a custom Mode to Monitor section in xorg.conf 
2. rerun system-config-display 
3. 
     
 
Actual Results:  Failure/crash 
 
Expected Results:  Either backup to xorg.conf.bak and continue 
parsing out what is necessary, or gracefully exit with a warning. 
 
Additional info: 
 
I added Mode to Monitor section to override the default mode order 
from the highest down. DELL 1703FP prefers 1280x1024@60Hz over 
allowed 1280x1024@75Hz. Hence, I need my xorg.conf.

Comment 1 Alexei Podtelezhnikov 2004-09-30 06:09:41 UTC
Created attachment 104566 [details]
xorg.conf to choke on

Comment 2 Alexei Podtelezhnikov 2004-09-30 06:12:37 UTC
Created attachment 104568 [details]
symptoms

Comment 3 Paul Nasrat 2004-09-30 07:12:36 UTC
Created attachment 104569 [details]
xorg.conf using UseModes

OK we assume that you use mode of the form of 1280x1024 rather than arbitrary
strings.  We need to fixup it barfing, we also need to fix it so that if we
lookup modes and get the resolution info rather than assuming it's in the name.


A workaround may be to use a Modes section (using resolution  with Identifier
"Optimum" and UseModes Optimum. Does the attache dxorg.conf work for you - it
may need some tweaking, but it should override the default 1280x1024 mode for
you.

Comment 4 Alexei Podtelezhnikov 2004-09-30 15:02:06 UTC
There should be no quotation marks in the ModeLine, ie, +HSync 
instead of "+Hsync". It works then. 
 
Using "1280x1024" string overrides the whole set of default modes, 
effectively killing off 75Hz completely. You have to also add 75Hz 
ModeLine in the Modes section after 60Hz to revive it. Using 
"Optimum", we do not change default resolutions but rather just move 
60Hz ahead of 75Hz effectively. Therefore I still prefer using custom 
names. 

Comment 5 Paul Nasrat 2004-09-30 15:09:42 UTC
I can understand that. I need to fix s-c-display to deal with this
though.  I was just suggesting a work around off the top of my head
until I can release an update which will handle custom names correctly.

Thanks for the feedback

Comment 6 Alexei Podtelezhnikov 2004-09-30 19:24:13 UTC
On a side note (worthy of a separate bugreport), shouldn't Xorg-x11 
pick up the correct optimum resolution itself without customizing 
xorg.conf? After all Dell monitor communicates it via ddc. For 
example, read-edid-1.4.1 recognizes the optimum resolution. Why can't 
Xorg do the same? This whould spare us a lot of trouble, and custom 
Mode strings could be just ignored by system-config-display.

Comment 7 Matthew Miller 2005-04-26 16:04:02 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 8 Alexei Podtelezhnikov 2005-06-20 23:58:59 UTC
Reproduced in Fedora Core 4.

Comment 9 Christian Iseli 2007-01-22 11:02:52 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 10 Adam Jackson 2007-04-03 18:22:10 UTC
NEEDINFO timeout, resolving as INSUFFICIENT_DATA.  If you are still experiencing
this bug in FC6 or FC7, please reopen.  Thanks for the report!


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