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.
Can you go to VC2 and run ddcprobe there? Does ddcprobe at least identify the video card correctly?
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?
This defect is considered SHOULD-FIX for Fairfax
After install, you can run 'kudzu -p -b ddc'.
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
I nearly forgot - this worked in Beta 1....
Does it still behave badly with Beta 3?
Bill, does this look like a kudzu problem?
Very possibly. This is confusing - the DDC code hasn't changed since sometime in the 7.1 beta cycle.
yeah, I checked. Still bad in Beta3, worked in all prior versions of RHL that supported ddc probes
Bill any ideas?
Not really. The code is the same. What happens if you build kudzu with egcs-1.1.2, by any chance?
Changing component to kudzu.
I'll gladly test such a beast, if someone will provide a binary.
Created attachment 27633 [details] ddcprobe built with egcs-1.1.2
There you go. Also, if you run the kudzu from 7.1 with 'kudzu -p -b ddc', what does it say?
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
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*
What happens if you boot the beta1 (or earlier) kernel?
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.
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....
Bah. Installed beta 1 kernel (thank the gods for MC, since rpm refused to) and got the same results. Dang.
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?
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.
Presumably this still fails?
Closing out bugs on older, no longer supported releases. Apologies for any lack of response. Please attempt to confirm with more recent releases.