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 horizontal frequency: 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): How reproducible: Always Steps to Reproduce: 1. Install RH9, Severn, or Rawhide or run redhat-config-xfree86 Actual Results: Wrong monitor selected. Expected Results: Right monitor selected Additional info:
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: http://www.ita.sel.sony.com/bin/support/support.cgi?whichone=1&installfile=sonyminf.txt&downloadfile=SONYMINF.EXE 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 require.
Created attachment 94169 [details] XFree86 Log
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.