Bug 117327 - s-c-d crashes on ModeLines with unusual names
Summary: s-c-d crashes on ModeLines with unusual names
Alias: None
Product: Fedora
Classification: Fedora
Component: rhpl   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
Reported: 2004-03-02 21:09 UTC by Moritz Barsnick
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-04 22:46:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XF86Config which causes s-c-d to crash (3.86 KB, text/plain)
2004-03-04 21:18 UTC, Moritz Barsnick
no flags Details

Description Moritz Barsnick 2004-03-02 21:09:34 UTC
Description of problem:
system-config-display terminates at startup if XF86Config contains 
manually crafted ModeLines which have "uncommon" names, such as 
"1024x768@85", accepting only lines of the sort "1024x768".

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. manually add such a ModeLine to /etc/X11/XF86Config:
ModeLine "1600x1000@91" 215.50 1600 1688 2104 2264 1000 1003 1016 
1046 #91Hz
2. call system-config-display
Actual results:
(system-config-display:10492): Gtk-WARNING **: GModule initialization 
check failed: Gtk+ version too old (micro mismatch)
* ddcprobe returned bogus values:
ID:   SNY00ea
Name: SNY00ea
HorizSync: None
VertSync:  None
Traceback (most recent call last):
  File "/usr/share/system-config-display/xconf.py", line 348, in ?
    hardware_state = XF86HardwareState(xconfig)
  File "/usr/lib/python2.3/site-packages/rhpl/xhwstate.py", line 146, 
in __init__
  File "/usr/lib/python2.3/site-packages/rhpl/xhwstate.py", line 275, 
in init_from_xconfig
    self.all_resolutions.sort (compare_resolution)
  File "/usr/lib/python2.3/site-packages/rhpl/xhwstate.py", line 50, 
in compare_resolution
    a1 = resolution_area(res1)
  File "/usr/lib/python2.3/site-packages/rhpl/xhwstate.py", line 46, 
in resolution_area
    (w, h) = resolution_from_string(res)
  File "/usr/lib/python2.3/site-packages/rhpl/xhwstate.py", line 43, 
in resolution_from_string
    return (string.atoi(w), string.atoi(h))
  File "/usr/lib/python2.3/string.py", line 220, in atoi
    return _int(s, base)
ValueError: invalid literal for int(): 1000@91

Expected results:
Program UI starts.

Additional info:
(Dunno why ddcprobe fails, but that's not the reason.)
I need to craft ModeLines manually, because my 16/10 monitor a) 
reports stupid 4/3 lines, and b) I may want other resolutions or 
timings. I use programs such as "modeline" or online services, and 
all these use the syntax "1024x768@80" to differentiate the different 
vertical frequencies. s-c-d cannot parse this, and fails here 
("/usr/lib/python2.3/site-packages/rhpl/xhwstate.py", line 43):

def resolution_from_string(res):
    (w, h) = string.split (res, "x")
    return (string.atoi(w), string.atoi(h))

Any chance in making this possible?

Comment 1 Brent Fox 2004-03-03 17:11:48 UTC
Can you attach your XF86Config file?

Comment 2 Moritz Barsnick 2004-03-04 08:36:27 UTC
Sorry about the delay - I'm at work now, will attach the file in 
about 10 hours.

Comment 3 Moritz Barsnick 2004-03-04 21:05:29 UTC
Okay, here's the config file. Hope this helps.

Comment 4 Moritz Barsnick 2004-03-04 21:18:39 UTC
Created attachment 98302 [details]
XF86Config which causes s-c-d to crash

Is it perhaps the "Modes" line, and not the Modeline itself?

Comment 5 Brent Fox 2004-03-04 22:46:32 UTC
The parser is expecting the "Modes" section to begin with something
like "1024x768"...not "1024x768@56".  I've modified the parser a
little to handle this situation.  It's still not smart enough to
handle more random names.  For example, if somebody created a ModeLine
called "Foobar" and then created a Modes line with "Foobar" in it, the
parser would break even though the file would be syntactically correct.

Should be fixed in rhpl-0.130-1.  Thanks for your report.

Comment 6 Moritz Barsnick 2004-03-05 18:38:29 UTC
Indeed, rhpl-0.131-1 works fine. Thanks!

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