Bug 103483 - Sony Multiscan 15sf2 detected as Sony GDM-20SHT
Sony Multiscan 15sf2 detected as Sony GDM-20SHT
Status: CLOSED WONTFIX
Product: Red Hat Linux Beta
Classification: Retired
Component: kudzu (Show other bugs)
beta1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-31 22:44 EDT by Steve Bergman
Modified: 2014-03-16 22:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-19 21:48:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of ddcprobe (238 bytes, text/plain)
2003-09-01 00:22 EDT, Steve Bergman
no flags Details
XFree86 Log (38.42 KB, text/plain)
2003-09-03 10:24 EDT, Steve Bergman
no flags Details

  None (edit)
Description Steve Bergman 2003-08-31 22:44:26 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:
Comment 1 Mike A. Harris 2003-08-31 23:28:32 EDT
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.
Comment 2 Steve Bergman 2003-09-01 00:22:03 EDT
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
Comment 3 Mike A. Harris 2003-09-01 01:27:27 EDT
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.
Comment 4 Steve Bergman 2003-09-03 10:24:38 EDT
Created attachment 94169 [details]
XFree86 Log
Comment 5 Brent Fox 2004-02-19 21:00:23 EST
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.
Comment 6 Brent Fox 2004-02-19 21:15:50 EST
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'.
Comment 7 Bill Nottingham 2004-02-19 21:48:23 EST
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.

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