|Summary:||DDC probed monitor durring install shows garbage|
|Product:||[Retired] Red Hat Linux||Reporter:||Kevin - The Alchemist - Sonney <alchemist>|
|Component:||kudzu||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED WONTFIX||QA Contact:||Brock Organ <borgan>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-02-04 22:55:25 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kevin - The Alchemist - Sonney 2001-07-28 22:59:58 UTC
Durring my install of fairfax B2 (Workstation, custom disk w/druid, KDE, GNOME, Games), The DDC probem monitor displays as "_W^fefe" instead of the 996something-or-other this monitor has been detected as in every prior anaconda was introduced. Monitor is a AOC Spectrum9Glrs The Horiz & vert sync settings are correct. This is an issue in the display field only.
Comment 1 Brent Fox 2001-07-29 02:01:38 UTC
Can you go to VC2 and run ddcprobe there? Does ddcprobe at least identify the video card correctly?
Comment 2 Kevin - The Alchemist - Sonney 2001-07-29 15:06:42 UTC
I'll have to re-run the install to get the specific output, but anaconda had properly displayed my video card (voodoo3). it was just a bad display string in the monitor selection screen. Is ddcprobe installable from somewhere on the cdrom, so I don't have to re-run the installer just to get ddcprobe output?
Comment 3 Glen Foster 2001-07-30 19:45:41 UTC
This defect is considered SHOULD-FIX for Fairfax
Comment 4 Bill Nottingham 2001-07-30 19:52:03 UTC
After install, you can run 'kudzu -p -b ddc'.
Comment 5 Kevin - The Alchemist - Sonney 2001-07-30 20:47:53 UTC
Ran it. The video card is proped properly on the agp bus (Voodoo 3), while the monitor probe returns : class: MONITOR bus: DDC detached: 0 driver: unknown desc: "(null)" id: _W^fefe mode: 2280x1425 mode: 2280x1425 mode: 2280x1425 mode: 2280x1425 mode: 2280x1425 mode: 2280x1425 mode: 2280x1425 mode: 2280x1425 mem: 16384
Comment 6 Kevin - The Alchemist - Sonney 2001-07-30 20:51:34 UTC
I nearly forgot - this worked in Beta 1....
Comment 7 Brent Fox 2001-08-03 16:30:01 UTC
Does it still behave badly with Beta 3?
Comment 8 Brent Fox 2001-08-03 16:30:56 UTC
Bill, does this look like a kudzu problem?
Comment 9 Bill Nottingham 2001-08-03 16:33:41 UTC
Very possibly. This is confusing - the DDC code hasn't changed since sometime in the 7.1 beta cycle.
Comment 10 Kevin - The Alchemist - Sonney 2001-08-03 18:07:44 UTC
yeah, I checked. Still bad in Beta3, worked in all prior versions of RHL that supported ddc probes
Comment 11 Michael Fulbright 2001-08-13 15:30:21 UTC
Bill any ideas?
Comment 12 Bill Nottingham 2001-08-13 16:13:10 UTC
Not really. The code is the same. What happens if you build kudzu with egcs-1.1.2, by any chance?
Comment 13 Brent Fox 2001-08-13 22:15:46 UTC
Changing component to kudzu.
Comment 14 Kevin - The Alchemist - Sonney 2001-08-13 23:02:11 UTC
I'll gladly test such a beast, if someone will provide a binary.
Comment 15 Bill Nottingham 2001-08-13 23:20:05 UTC
Created attachment 27633 [details] ddcprobe built with egcs-1.1.2
Comment 16 Bill Nottingham 2001-08-13 23:20:44 UTC
There you go. Also, if you run the kudzu from 7.1 with 'kudzu -p -b ddc', what does it say?
Comment 17 Kevin - The Alchemist - Sonney 2001-08-13 23:30:17 UTC
Runnign kudzo command line says exactly what ddc on the command line says (see prior comment on 7/30). Newly built file says : EDID ver. 254 rev. 254. Manufacturer: _W^ ID: fefe EISA ID: _W^fefe Serial number: fefefefe. Manufactured in week 254 of 2244. Input signal type: composite sync, sync on green, digital signal. Screen size max 254 cm horizontal, 254 cm vertical. Gamma: 3.540000. DPMS flags: RGB, active off, suspend, standby. Established timings: 720x400 @ 88 Hz (XGA2) 640x480 @ 60 Hz (VGA) 640x480 @ 67 Hz (Mac II, Apple) 640x480 @ 72 Hz (VESA) 640x480 @ 75 Hz (VESA) 800x600 @ 56 Hz (VESA) 800x600 @ 60 Hz (VESA) 800x600 @ 75 Hz (VESA) 832x624 @ 75 Hz (Mac II) 1024x768 @ 87 Hz Interlaced (8514A) 1024x768 @ 60 Hz (VESA) 1024x768 @ 70 Hz (VESA) etc. etc. Proper timings, bad ID & Manufacturer
Comment 18 Kevin - The Alchemist - Sonney 2001-08-13 23:32:03 UTC
FWIW, I *CAN* bring the monitor by RH HQ in RTP this week if y'all want to test it there. Of course, If I have to leave it over night, I'll need a comperable loaner *grin*
Comment 19 Bill Nottingham 2001-08-13 23:36:09 UTC
What happens if you boot the beta1 (or earlier) kernel?
Comment 20 Kevin - The Alchemist - Sonney 2001-08-14 01:34:45 UTC
Sure, make me dig for the beta 1 CDs I was *JUST* about to toss. I'll test tomorrow, when I have some time to do so. It probed OK under seawolf, I remember that.
Comment 21 Bill Nottingham 2001-08-14 01:38:48 UTC
OK. I'm just testing variables at this point; the code hasn't changed, the old binary also fails, and it fails when rebuilt with the 'known good' compiler, so I don't *think* it's a kudzu problem at this point....
Comment 22 Kevin - The Alchemist - Sonney 2001-08-14 12:25:35 UTC
Bah. Installed beta 1 kernel (thank the gods for MC, since rpm refused to) and got the same results. Dang.
Comment 23 Jay Turner 2002-03-19 14:32:25 UTC
OK, so not quite sure what I should be doing with this issue. Doesn't appear that it is a kudzu issue . . . does the issue still occur with the betas of Hampton?
Comment 24 Kevin - The Alchemist - Sonney 2002-03-19 15:13:32 UTC
Yes, Hampton 1 and Hampton 2 both exhibited this issue. So, what can we do? If this is happening just with this 9glrs, I'll call it a bad monitor chip and live with it. However, since it worked with 7.1 and earlier, I highly doubt that. My offer still stands to bring the monitor down to Centenial so y'all can poke at it.
Comment 25 Bill Nottingham 2002-07-11 20:45:51 UTC
Presumably this still fails?
Comment 26 Bill Nottingham 2005-02-04 22:55:25 UTC
Closing out bugs on older, no longer supported releases. Apologies for any lack of response. Please attempt to confirm with more recent releases.