Bug 79669 - kudzu does not seem to handle swtiching monitors
kudzu does not seem to handle swtiching monitors
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kudzu (Show other bugs)
8.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-14 15:21 EST by Jens Knutson
Modified: 2014-03-16 22:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-23 15:51:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jens Knutson 2002-12-14 15:21:27 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021203

Description of problem:
Kudzu does not appear to detect changes in monitors between reboots.

How reproducible:
Always

Steps to Reproduce:
1. Use a Red Hat Linux 8 machine with a given monitor
2. Turn off computer and connect a new monitor to the same PC (preferably a 
monitor that doesn't support the same res/refresh as the monitor from step 1 to
demonstrate how scary this is for the user)
3. Turn on computer again
4. Watch the new monitor choke on the new res/refresh rate

Actual Results:  X did not come up because the new monitor doesn't handle the
configured resolution of the old monitor

Expected Results:  kudzu should detect the new monitor and prompt to configure X
accordingly

Additional info:

This effectively breaks X, so I've set it to "High" for severity - I hope this
isn't improper.
Comment 1 Bill Nottingham 2002-12-16 19:29:20 EST
Currently, the DDC monitor probe is only done on-demand by config tools, as it
has caused strange behavior in the past on some graphics chipsets. So, it's not
actually run during the boot time probe.
Comment 2 Jens Knutson 2002-12-16 21:07:44 EST
Bleh... well, would a "probe by default unless the chipset appears on this
blacklist" system be possible, or is that still too dangerous?
Comment 3 Bill Nottingham 2005-09-23 15:51:39 EDT
Realistically, where it has fallen down seems related almost as much to BIOS as
it does chipset. Which makes this impractical.

The long-term solution is to have the X driver automatically adjust to monitor
changes; that is where progress will be made. Until then, it's unlikely that the
behavior in kudzu will change. Therefore, closing this bug.

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