duplicate of #70190 and #74424

clearly NOT a dupe of #70190 -- checking the other ...

nope, not  #74424 either -- these areboth  DCC related, not video card 
related, which is the esence of my filing. ...

it is: the "ddcprobe returned bogus values" is values about the MONITOR,
and the bogus sync values in the 0xF000 range is exactly the symptom of the
bug in the two reports above. Because the sync ranges are bad,
redhat-config-xfree86 doesn't create a working XF86Config and therefore
doesn't start.

Interesting approach -- Randomly bad and missing DCC capabilities, and bogus 
DCC values are a fact of life -- and will be forever -- dumb KVM's and 
presentation projectors regularly trash the ability of the tool to rely on 
values received --  
 
So your point is that a fallback mechanism for a purely textual setup is still 
needed?  'The spirit is willing, but the (hardware) flesh is weak.'

I see the same issue with my Compaq Deskpro2000 P166MMX system when running RH 
8.0.  S3 V2/GX onboard video.  1 MB RAM.  Proview 510 Monitor.  This same 
hardware works fine with RH 7.2.  I have not yet tested it with RH 7.3.  The 
closest I get with RH 8.0 is running a vncserver session (whose X display is 
vncserver).  It appears that X and GNOME work, just not on the local video 
card.  (I've tried switching monitors as well with no luck).  Let me know if 
you want to see a vnc session on this machine.

Actually, I think the problem is that the monitor isn't in the MonitorsDB file.
 Can you provide more information about your monitor?  

The following monitors look similar, but as you can see, there's no entry for
'gsm427d', which is what ddcprobe says the EISA ID is on your monitor.

LG Electronics Inc.; LG StudioWorks 74i; gsm4278; 30.0-50.0; 50.0-90.0; 1
LG Electronics Inc.; LG StudioWorks 74m; gsm4277; 30.0-50.0; 50.0-90.0; 1
LG Electronics Inc.; LG StudioWorks 76m; gsm4273; 30.0-65.0; 50.0-110.0; 1
LG Electronics Inc.; LG StudioWorks 78D; gsm427f; 30.0-85.0; 50.0-120.0; 1
LG Electronics Inc.; LG StudioWorks 78m; gsm4274; 30.0-85.0; 50.0-120.0; 1
LG Electronics Inc.; LG StudioWorks 7D; gsm427e; 30.0-65.0; 50.0-120.0; 1

ping?  anyone?

The kudzu bug in ddcprobe is fixed in RHL 8.0.94,
as a result anaconda still complains about bogus
values, this time HorizSync: None

That all from my part, I have no idea whether it
works for the original reporter with the hardware
in question.

ok, what is the values that ddcprobe outputs now?

(The machine isn't online, so this is reconstructed. I can get the real
values, if they are really needed.)

******
Monitor DDC probe results
ID: <something here>
Name: <something here>
Width (mm): <something here>
Height(mm): <something here>
******

Note the absence of 
Horizontal Sync (kHZ):
Vertical Sync (HZ)  :
entries (which is right, kudzu doesn't give that info).

Anaconda then outputs
******
ddcprobe returned bogus values:
ID:   <something here>
Name: <something here>
HorizSync: None
VertSync:  None
******
and on tty1, monitor is "not detected"

Without the actual values, I can't add the monitor to the MonitorsDB file.

bfox: I missed your ping ... sorry.

I readily confess amazing ignorance on the topic of monitor capabilities
discernment techniques. ;)  -- What command line should I run to provide the
returned monitor values being returned beyond that quoted above?

The binary seems to be: ddcprobe, which on my host at work (not the one
provoking the initial report) with the results shown is running X at 1024x or
800x -- (I fergit) -- and the returned values look way bad just the same to me 

-- how are they do be interpreted?  no man page is evident.  

[herrold@oldnews herrold]$ sudo /usr/sbin/ddcprobe
Password:

Videocard DDC probe results
Description:  ATI Technologies Inc. MACH64GT
Memory (MB):  4

Monitor DDC probe results
ID: SGX1000
Horizontal Sync (kHZ): -268377405--268376042
Vertical Sync (HZ)  : -268376042--268370092
Width (mm): 330
Height(mm): 240
[herrold@oldnews herrold]$ man ddcprobe
No manual entry for ddcprobe
[herrold@oldnews herrold]$ rpm -qf /usr/sbin/ddcprobe
rhpl-0.51-1
[herrold@oldnews herrold]$ rpm -qi rhpl
Name        : rhpl                         Relocations: (not relocateable)
Version     : 0.51                              Vendor: Red Hat, Inc.
Release     : 1                             Build Date: Thu 29 Aug 2002 04:45:10
PM EDT
Install date: Tue 17 Sep 2002 10:00:46 AM EDT      Build Host: daffy.perf.redhat.com
Group       : System Environment/Libraries   Source RPM: rhpl-0.51-1.src.rpm
Size        : 652272                           License: GPL
Signature   : DSA/SHA1, Tue 03 Sep 2002 05:37:10 PM EDT, Key ID 219180cddb42a60e
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : Library of python code used by programs in Red Hat Linux
Description :
The rhpl package contains Python code used by programs in Red Hat Linux.
[herrold@oldnews herrold]$

I have a machine available with this bug.  Please contact me and I can give 
someone at Redhat shell access to the machine.  jg

herrold, ddcprobe probes the monitor hardware for the ID, the name, and hsync
and vsync rates.

What we really want to get from the monitor is the ID.  Once we get the ID, we
look it up in the /usr/share/hwdata/MonitorsDB file.  If we can find it in the
database, we use the hsync and vsync rates from the database.  

If we can't find an entry for the monitor in the database, we try to use the
hsync and vsync rates that ddcprobe returns.  In your case, the monitor isn't
listed in the database, but the hsync and vsync rates that your monitor's
hardware returns is negative.  Negative refresh rates are generally nonsensical.  :)


From the ddcprobe results that you've attached, it looks like you are dealing
with two different monitors.  Both are seem to be returning bogus hsync and
vsync values.  

The two IDs in question are: GSM427d and SGX1000.  Can you tell me what the make
and model of these monitors are?  Once I have that, I'll try to find the
hardware specs so that we can add the correct name, hsync and vsync settings to
the MonitorsDB file.

Jerry, we can't really do that sort of thing.

(Re: comment #7 above)

ddcprobe returns the following for a Proview 510 monitor:

Videocard DDC probe results
Description:  S3 Incorporated. Trio64V2/DX/GX
Memory (MB):  1

Monitor DDC probe results
ID: PTS061a
Horizontal Sync (kHZ): -268377405--268395568
Vertical Sync (HZ)  : -268395568--268370092
Width (mm): 280
Height(mm): 210

Brent: Again, the negative refresh rates are a kudzu bug, fixed
in RHL 9. In fact the hardware doesn't report the refresh rates.

Not that this would help adding the monitor to the database ;-)

[herrold@oldnews dl]$ sudo rpm -Uvh
/home/herrold/redhat/RPMS/i386/kudzu-1.1.1-1.1.i386.rpm
/home/herrold/redhat/RPMS/noarch/hwdata-0.75-1.noarch.rpm
Preparing...                ########################################### [100%]
   1:hwdata                 ########################################### [ 50%]
   2:kudzu                  ########################################### [100%]
[herrold@oldnews dl]$ sudo ddsprobe
sudo: ddsprobe: command not found
[herrold@oldnews dl]$ sudo ddcprobe

Videocard DDC probe results
Description:  ATI Technologies Inc. MACH64GT
Memory (MB):  4

Monitor DDC probe results
ID: SGX1000
Width (mm): 330
Height(mm): 240
[herrold@oldnews dl]$

------------------------------------------

It would appear that an update against RawHide confirms this.

The SGX1000 is a 17" rebranded Sony Trintron, from SGI.  

Front reads: Silicon (logo) Graphics

Rear data plate reads:

Model GDM-17E21
Color Graphic Display
FCC ID: AKBGDM17SE2T
DoM 8/96

both VGA and 5 input BNC - R G B HD VD

But frankly, not seeing bogus Hsync and VSync rate information is OK but this
monitor configured itself with Xconfigurator, and seems not to be getting info
with the ddcprobe

Other monitor is offline, and I hope to get it tonight.

I fixed my video issue.  This is what I did.
1.  Installed vnc.
2.  Ran vncviewer from remote host to get graphical session.
3.  From the Redhat start menu, select "System Settings => display".
4.  Change driver from "s3" to "vesa".

Please note that the ddcprobe issue still exists, but the above method allows 
me to select a different video driver.  Also, when I probe the video card, the 
driver RH8.0 wants to use is "s3", corresponding to S3 Trio64V2 (generic).  
There appear to be 4 drivers:  s3, s3virge, savage, vesa.  The only one that 
worked for my Compaq Deskpro 2000 P166MMX was the vesa driver.

My suggestion is to get vnc installed and attempt to select a driver from a 
graphical session.  Good luck!

and here is that first monitor -- originally used with a Mac system -- again
with 15pin VGA and R G B H V BNC inputs

plate sez: PowerComputing
Model PCC51189
DoM   Oct 1996
FCC   BEJCF786

I can manually dial it up top 1280 x 1024 with no problem with the generic --
but the r-c-xf tool only offers the 800x600

I tried teh 1600 x 1200 -- but without a 'test it' button, had to go manually
depete teh config file to use the R-C-xf tool again without options.

PLEASE resonsider adding a 'test it' button, to let the user experiment without
penalty of needing mharris level knowledge of troubleshooting when one pushes
toop far.  This is basic in the Apple HUI Design specs -- and it just makes sense.

Anyway, here is the rest... As initial submitter, once the two monitors I
reported are int eh hwdatabase, I am OK with a Close/RawHide


[herrold@dhcp249 herrold]$ sudo rpm -Uvh  \
      /home/herrold/rpmbuild/RPMS/i386/kudzu-1.1.3-1.1.i386.rpm
Preparing...                ########################################### [100%]
   1:kudzu                  ########################################### [100%]
[herrold@dhcp249 herrold]$ ddcprobe
-bash: ddcprobe: command not found
[herrold@dhcp249 herrold]$ sudo ddcprobe
sudo: ddcprobe: command not found
[herrold@dhcp249 herrold]$ sudo /usr/sbin/ddcprobe

Videocard DDC probe results
Description:  NVidia Riva 128 Eval Card
Memory (MB):  4

Monitor DDC probe results
ID: GSM427d
Width (mm): 330
Height(mm): 250
[herrold@dhcp249 herrold]$

Ok, I added the SGI monitor to the database.

I can't find any information on the web about the PowerComputing PCC51189 except
for
http://lists.terrasoftsolutions.com/pipermail/yellowdog-newbie/2003-May/002915.html
which doesn't really help me because it doesn't tell me the correct Hsync and
Vsync settings for the monitor.  Ddcprobing the monitor doesn't tell us that
either.  At this point, I'm going to write off the PowerComputing monitor as
unsupported.  

SGI monitor should appear in hwdata-0.93