Bug 101550 - Specific Sony monitor not recognized, even though it was in RHL9 install
Summary: Specific Sony monitor not recognized, even though it was in RHL9 install
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: redhat-config-xfree86
Version: beta1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-03 16:41 UTC by Gerry Tool
Modified: 2007-04-18 16:56 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2003-08-15 18:36:13 UTC

Attachments (Terms of Use)

Description Gerry Tool 2003-08-03 16:41:37 UTC
Description of problem: Sony CPD-G410R monitor not recognized on install, even
though it was in RHL9.

Version-Release number of selected component (if applicable):

How reproducible: Always

Steps to Reproduce:
1.Install Severn (new install)
2.X setup shows generic monitor instead of specific monitor
Actual results:  Generic monitor selected.  Forced to look at list available and
can select only a closely related monitor, the CPD-G400 which has slightly lower

Expected results: Fresh install of RHL9 correctly identifies my specific monitor
and sets its properties correctly, even though this monitor is not listed in the
database of monitors from which one can manually select.  Since RHL9 had this
capability, I expect it to be in the next release also.

Additional info:

Comment 1 Mike A. Harris 2003-08-03 21:47:37 UTC
Not an XFree86 problem, the X server just uses what it is configured to use. If
the config tool isn't configuring or detecting things properly, that is a config
tool problem.

The monitor database should have the same entries as it did in RHL 9 plus new
entries.  I've not removed any (nor would I have any reason to), so if something
isn't detecting, it's a tool problem.

Reassigning to redhat-config-xfree86

Comment 2 Brent Fox 2003-08-15 01:02:14 UTC
As root, run /usr/sbin/ddcprobe.  What does the output say?

Comment 3 Gerry Tool 2003-08-15 01:37:25 UTC
Results on RHL9
[root@gstpc gerry]# /usr/sbin/ddcprobe
Videocard DDC probe results
Description:  ATI Technologies Inc. V200
Memory (MB):  64
Monitor DDC probe results
ID: SNY0191
Name: CPD-G410R
Horizontal Sync (kHZ): 30-110
Vertical Sync (HZ)  : 48-170
Width (mm): 360
Height(mm): 270

Results on Severn
[root@gstpc root]# /usr/sbin/ddcprobe
Videocard DDC probe results
Description:  ATI Technologies Inc. V200
Memory (MB):  64
Monitor DDC probe results
ID: SNY0191
Name: CPD-G410R
Horizontal Sync (kHZ): 30-110
Vertical Sync (HZ)  : 48-170
Width (mm): 360
Height(mm): 270
As can be seen above, both systems probe the monitor just fine.  The problem
noted was that during a fresh  install of severn with anaconda, the monitor was
not recognized, and was listed during install as a Generic monitor.  It listed
sync values that were close - they were the values associated with the Sony
CPD-G400 monitor which is listed in the database.  The CPD-G410R is not listed
in the database.

As an aside, today I installed Taroon on another partition of this same machine,
and it did properly recognize the montior during anaconda install.

Comment 4 Brent Fox 2003-08-15 18:36:13 UTC
I have added the monitor to the database, which should fix the problem.  Fix
should appear in hwdata-0.90-1.1

Comment 5 Mike A. Harris 2003-08-15 20:45:45 UTC
If the monitor wasn't in the database and just got added now, then there is no
way that it could have been autodetected in RHL 9.

Comment 6 Gerry Tool 2003-08-15 23:08:58 UTC
Well, there is certainly some confusion here.  There must be TWO databases. 
Yesterday when I did a fresh install of taroon on a newly formatted partition,
anaconda immediately identified my Sony CPD-G410R monitor.  However, when I log
into taroon, or RHL9, and use the menu item System Settings > Display > Advanced
> Configure > Monitor Settings, under Sony, there is no CPD-G410R, only a
CPD-G400.  I have not logged into severn before writing this, but I recall that
Display has a different dialog on severn than it does on RHL9 or taroon; there
is no way to manually set the horizontal/vertical dpi on that dialog.  That may
be related to why severn did not identify the monitor and the RHL9 and taroon
did.  I believe that the CPD-G410R monitor is not in the list of monitors there
either.  I'll check that and add another comment.

Comment 7 Gerry Tool 2003-08-15 23:19:52 UTC
Yes, severn does have a different dialog than RHL9 and taroon which share the
same one.  Also, severn's list of monitors in the Advanced Settings > Monitor
tab does not include the CPD-G410R.  Another part of the mystery is that lacking
the choice of a CPD-G410R, I had chosen CPD-G400 in severn as close enough. 
However, since I executed /usr/sbin/ddcprobe as requested by Brent Fox
yesterday, severn now lists my monitor as a CPD-G410R.  Evidently ddcprobe had a
different lookup list than the one provided in the Advanced Settings > Monitor

I take issue with M. Harris statement "If the monitor wasn't in the database and
just got added now, then there is no way that it could have been autodetected in
RHL 9."

Comment 8 Mike A. Harris 2003-08-16 09:25:58 UTC
It's certainly understandable that due to your perceived frustration over this
problem, that you may take issue with anything presented by a developer which
might not make sense to you, at least in the way you view the problem.

As such, to put your mind at ease, I have just searched through the MonitorsDB
in both Red Hat Linux 8.0 and 9, and it clearly shows that the Sony CPD-G410R
monitor referenced in this bug report is not listed in either OS release:

pts/52 mharris@devserv:~/rpmbuild$ grep -i CPD-G410R
pts/52 mharris@devserv:~/rpmbuild$ grep -i CPD-G410R
pts/52 mharris@devserv:~/rpmbuild$

What does this really mean though?  It means that this monitor was not ever
known to Red Hat Linux, nor was it ever listed in the monitor database (which
was my claim above).

There is only one single way that this monitor would be seen to the installer
as a Sony CPD-G410R at all, and that is via DDC probe.  The monitor's name
and model number are returned by the monitor itself, and are NOT known to
the OS distribution.  The config tool gets the PnP settings FROM the monitor
itself - not from any database.

Why this would not autodetect via DDC probing in Red Hat Linux 9 if it did in
Red Hat Linux 8.0 is another question, one which I don't have an answer to.
If you are using a KVM switch, or any other hardware in between the monitor
and video card which can interfere with the DDC signal, that could explain
the problem.  If you have changed video hardware in between releases, that
also could explain the problem as not all video drivers support DDC.

There are other possible scenarios also, but rest assured that as I stated
above, this monitor has not ever been known to Red Hat, nor has it ever been
part of the MonitorsDB database which ships with the distribution.  I hope this
clarifies what I've said above better and allays any confusion I may have


Comment 9 Gerry Tool 2003-08-16 11:28:17 UTC
Thank you for the added clarification, Mike.  Since I wrote the last comment, I
had suspected that the monitor info was being returned directly from the monitor
when it was correctly identified.  Note that the monitor was autodetected in
anaconda during my installation of both RHL9 and taroon, but not in severn.  I
suspect that RHL9 and taroon anaconda both use ddcprobe, whereas severn anaconda
must just look in the database.  This *may* also be related to the fact that the
Display setting applet in severn is different than the one that is used in both
RHL9 and taroon.

This difference is described in Comment #7 above and also in bug #101564 which
has  not been assigned.

Comment 10 Mike A. Harris 2003-08-16 13:10:12 UTC
DDC is the prefered method of monitor detection in all releases of Red Hat Linux
and Red Hat Enterprise Linux.

Without DDC working, there is absolutely no way to detect the monitor at all,
which means the user has to select the monitor from a list manually.

DDC specifically is what allows monitor autodetection, and if that doesn't
work, it is not possible to autodetect the monitor.

I do not know what the current config tools are doing, however they should
be trying ddcprobe first to autodetect the monitor, and then using the
data returned from the monitor in the config file, and completely ignoring
the monitor database.  If your monitor was in fact autodetected in previous
OS releases ok, it is because DDC worked, which is expected.  In that case,
your monitor will be properly configured based on the information the monitor
itself provides.

The only problem here, is when the monitor is _not_ autodetected via DDC
probing, either because the monitor doesn't support it, the video card
doesn't support it, the video driver doesn't support it or doesn't support
DDC with the particular configuration (such as DVI panels quite often), or
if something is interfering with DDC such as a KVM or other device.  There
are other possibilities also.

If DDC monitor autodetection fails for any reason, then the monitor simply
can not be autodetected at all, and the user must manually select it from
a list.  In this case, that monitor was not in the MonitorsDB file which
is the database of all known monitors, and so manual monitor selection would
be impossible.

Brent has indicated above, that this monitor was added to the monitor database
by him just recently.  However, that just allows the monitor to be selected
manually, and should have no bearing, at least IMHO on monitor autodetection.

IMHO, this problem should theoretically still exist.  Wether it is a bug or
not isn't clear however, as autodetection can fail for reasons other than
a bug being present - I've stated some of those reasons above.

Try using the latest hwdata package nonetheless and see what happens.

Brent, does the tool now use DDC primarily and then use the info reported
by the monitor in the config file?  Or does it use the monitorDb file too?

IMHO, we should be using DDC exclusively if it works, and since the X server
uses DDC by default too, if the config tool can DDC detect a monitor, then
we shouldn't be putting anything in the config file for horiz/vert, etc. as
the X server can detect those at runtime anyway.

Microsoft windows handles things like this:  If DDC is useable, it uses it in
all cases.  If DDC is not useable for any reason, it then falls back to
"safe" settings indicated in the registry.  You can test this by having your
display set to high res/refresh, and then rebooting but turning the monitor off.
When Windows starts, it can't DDC the monitor as it is off.  Windows will
back off the refresh rate to 60Hz to protect the display in case you've changed

Comment 11 Gerry Tool 2003-08-16 13:54:04 UTC
Well, Mike and Brent, I must apologize for wasting your time.  I decided to make
a test by starting a fresh install of severn from the cds.  THIS time, severn
immediately probed and identified the monitor.  I don't know what went wrong
with my original severn install.  There has been no change in my system during
all this time (since before RHL9).  I do not use a KVM. I have a Radeon (built
by ATI) 7500 card, and the monitor you now know well.

So, this appears to have been an anomally, NOTABUG.  In the future when I see a
problem during install, I will repeat the process before reporting a bug.

Thanks for adding the monitor to the DB just in case I have to manually select
it sometime.

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