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 3. 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 capabilities. 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:
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
As root, run /usr/sbin/ddcprobe. What does the output say?
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.
I have added the monitor to the database, which should fix the problem. Fix should appear in hwdata-0.90-1.1
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.
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.
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 dialog. 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."
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 hwdata-0.47/hwdata-0.47/MonitorsDB pts/52 mharris@devserv:~/rpmbuild$ grep -i CPD-G410R hwdata-0.75/hwdata-0.75/MonitorsDB 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 caused. Thanks
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.
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 monitors.
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.