Bug 72734 - RFE: keep old monitor info if no ddc
RFE: keep old monitor info if no ddc
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-xfree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
David Lawrence
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2002-08-26 23:44 EDT by John Reiser
Modified: 2007-04-18 12:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-01 14:52:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Reiser 2002-08-26 23:44:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

Description of problem:
If DDC probe fails, then currently pyxf86config assumes bog-standard VESA VGA
for monitor, especially including HorizSync 31.5-37.9 and VertRefresh 50.0-70.0.
 So if the user changes the video card, then the existing monitor info must be
retrieved from XF86Config.backup.  This would be only annoying, except that
under the default graphical login there is no opportunity to edit XF86Config
after kudzu and before XF86Config is used.

Instead, if DDC probe fails, and if an old XF86Config exists, then by default
pyxf86config should preserve the old monitor info; and if pyxf86config is run
interactively, then there should be a question "Preserve old monitor info
(namely <model>, <freqs>)?" with a default of Yes.

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

How reproducible:
Didn't try

Steps to Reproduce:
1. Old video card: Cirrus Logic 5434-8; monitor: Sony Multiscan 15sf (FCC id
AK8CPD15SF1; Nov.1994) with no DDC.
2. Change video card to ATI Rage XL (PCI 0x1002,0x4752).
3. Kudzu detects change, user selects De-configure old card, user selects
Configure new card.  DDC Probe returns "None" four times.

Actual Results:  VESA VGA monitor info:
       HorizSync    31.5 - 37.9
       VertRefresh  50.0 - 70.0
       ModeLine     "1400x1050" 129.0 1400 1464 1656 1960 1050 1051 1054 1100
+hsync +vsync
       ModeLine     "1400x1050" 151.0 1400 1464 1656 1960 1050 1051 1054 1100
+hsync +vsync
       ModeLine     "1400x1050" 162.0 1400 1464 1656 1960 1050 1051 1054 1100
+hsync +vsync
       ModeLine     "1400x1050" 184.0 1400 1464 1656 1960 1050 1051 1054 1100
+hsync +vsync
       Option      "dpms"

Expected Results:  Keep old monitor info:
        HorizSync   31.0-64.0
        VertRefresh 50.0-120.0
        Option "dpms"

Additional info:
Comment 1 Alexander Larsson 2002-08-27 04:49:18 EDT
notting, I'm not sure what's being asked here. pyxf86config doesn't ever do dcc
probes. And redhat-config-xfree86 should be using the old X config file if it
existed (and --reconfig wasn't specified).

What is kudzu calling here?
Comment 2 Bill Nottingham 2002-08-27 11:56:04 EDT
kudzu just does the ddc probe; if they customized the monitor before, it won't
find it (and can't; there's no code to parse X config files in kudzu.)
Comment 3 Alexander Larsson 2002-08-28 03:30:47 EDT
So why was this bug assigned to pyxf86config?
It seems kudzu could easily use pyxf86config to read the old values if it wanted.
Comment 4 Bill Nottingham 2002-08-28 11:58:25 EDT
It was assigned because of the summary.

I don't think that's the right solution; I think perhaps redhat-config-xfree86
should default to the old values if when it calls kudzu it can't find a monitor.

Having the probe code itself go looking for old data could lead to false positives.
Comment 5 Alexander Larsson 2002-08-28 14:33:36 EDT
It already does, unless you pass --reconfig.
Or it's a bug.
Comment 6 Alexander Larsson 2003-01-17 07:43:24 EST
This is really a redhat-config-xfree86 bug.
Comment 7 Brent Fox 2004-03-01 14:52:11 EST
I have simplified the monitor selection screen in
system-config-display so I'm not sure if this behavior still happens.
 If you see this behavior with Fedora Core 1, please reopen this bug

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