Red Hat Bugzilla – Bug 103483
Sony Multiscan 15sf2 detected as Sony GDM-20SHT
Last modified: 2014-03-16 22:38:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Description of problem:
Anaconda and redhat-config-xfree86 both detect my Sony Multiscan 15sf2 as a Sony
GDM-20SHT. This occured in RH9, possibly RH8.0 and still occurs in Severn and,
I believe, Rawhide.
The frequencies are very close, however. The only difference being the
31.0 - 65.0 (correct) vs 30.0 - 65.0 (incorrect)
Not a big deal, I suppose.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install RH9, Severn, or Rawhide or run redhat-config-xfree86
Actual Results: Wrong monitor selected.
Expected Results: Right monitor selected
Can you run the following command, and attach the file generated to the
bug report using the bugzilla file attachment feature below:
ddcprobe > ddc.log
Also, if you have the floppy disk or CDROM which came with your monitor
originally, and can attach the Windows .INF file from your monitor's
driver disk, or can download the file from the manufacturer's website
perhaps, I could ensure that it is added to our database.
Thanks in advance for any information you can provide.
Created attachment 94108 [details]
Output of ddcprobe
Well, ddcprobe shows it as a GDM-20SHT (My God, where was their marketing
department when they selected that model name?! ;-)
However, it should be a CPD-15SF2.
So does ddcprobe read the string directly (as one might expect) or is there
some guessing involved?
Sorry, no .INF file. I've had the monitor for years and I usually lose that
stuff within weeks.
However, as I recall it is a 15 inch trinitron monitor, with 14.7" viewable
diagonal, .25 dot pitch.
31.5-65.0 kHz horizontal
50-120 Hz vertical
This looks like a bug in ddcprobe I think. IMHO, ddcprobe should be
returning the information straight from the monitor itself, however it
seems it is reading it from the data in the monitor database instead,
which I think is wrong anyway.
The monitor data in the monitor database matches the information from
Microsoft Windows however, supplied by sony:
The above file is an .EXE file, but it is a self extracting ZIP file that
unzips happily with 'unzip'.
Please attach your XFree86 log file, it should show the real data we
Created attachment 94169 [details]
This is a firmware bug with a number of Sony monitors. Instead of
reporting the EISA ID properly, they return "sny0000". There are
seven of Sony monitor models with this EISA ID, so when ddcprobe looks
up the number in the Monitor's database, it only has a one in seven
chance of being right.
The only fix I can think of is to change kudzu to pull the model name,
hsync, and vsync from the firmware as mharris suggested instead of
doing a lookup in the MonitorsDB. And then you'd only do the database
lookup if the info can't be found from the kudzu probe.
However, given that this only affects seven monitor models which have
buggy firmware, it seems like a lot of work for very little gain. I'd
also say that this solution also assumes that you can trust the rest
of the values from the firmware probe. However, if the EISA ID is
already wrong in the firmware, how reliable is the rest of the data
like the sync rates?
I'm going to change the component to the kudzu owner for him to
consider, but I would recommend closing as 'wontfix'.
Yeah, I don't think that changing the algo for 7 monitors would be
necessarily worth the effort, especially when I'm not even sure the
descriptions are even valid in the majority of the cases.