Bug 50240

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.