Bug 458747

Created attachment 314039 [details]
X log file

I had exactly the same symptoms with a Samsung Syncmaster 245T, where the problem appears to be completely idiotic EDID information being provided by the monitor.  From /var/log/Xorg.0.log:

...
(II) RADEON(0): EDID vendor "SAM", prod id 759
(II) RADEON(0): Using hsync ranges from config file
(II) RADEON(0): Using vrefresh ranges from config file
(II) RADEON(0): Printing DDC gathered Modelines:
(II) RADEON(0): Modeline "1920x540"x0.0   74.25  1920 2008 2052 2200  540 542 547 562 interlace +hsync +vsync (33.8 kHz)
(II) RADEON(0): Modeline "1920x540"x0.0   74.25  1920 2448 2492 2640  540 542 547 562 interlace +hsync +vsync (28.1 kHz)
(II) RADEON(0): Modeline "640x480"x0.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) RADEON(0): Output: DVI-0, Detected Monitor Type: 3
(II) RADEON(0): EDID data from the display on output: DVI-0 ----------------------
(II) RADEON(0): Manufacturer: SAM  Model: 2f7  Serial#: 814
(II) RADEON(0): Year: 2007  Week: 52
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Digital Display Input
(II) RADEON(0): Max Image Size [cm]: horiz.: 16  vert.: 9
(II) RADEON(0): Gamma: 2.20
...

Not surprisingly, the above is complete nonsense for a WUXGA-capable flat panel.

(In reply to comment #2)

> (II) RADEON(0): Max Image Size [cm]: horiz.: 16  vert.: 9

Aaw lame.  That's just aspect ratio not size.

(In reply to comment #0)
> Created an attachment (id=314038) [details]
> X config
> 
> The detected display size is way off, leaving the fonts and other DPI related
> things huge.  I have to use 'Option "IgnoreEDID" "true"' and '
> DisplaySize 520 325' in my xorg.conf to get the right size.

What display size do you get if you don't do this?

Okay, I tested a bunch of combinations: different video cards (ATI X700 XL and nVidia 6200 LE), on all three ports of the monitor (VGA, DVI, and HDMI).  The problem is the HDMI port (I swear I had seen the same on the DVI port but I don't now; maybe I didn't power cycle in between switching).  I'm using an HDMI-to-DVI cable to connect to the DVI port on each card (it is the cable I had available that was long enough).

With VGA and DVI on both video cards, I get 518x324mm (although then the nVidia rounds it to 520x320mm and ATI to 52x32cm, which is the wrong aspect ratio and DPI).

Apparently, Samsung considers the HDMI port for DVD players only or some such and wants to present a 16:9 aspect ratio.

For some reason though, Windows (XP Media Center) with the ATI card does get it right.  Is there a way for Linux to recognize certain bogus EDID results and override them?  I'm guessing that must be what Windows does.  It'd be nice if I didn't have to buy a new DVI-to-DVI cable just to get this right (it is a longer cable than I'm using for testing).

(In reply to comment #5)

> With VGA and DVI on both video cards, I get 518x324mm (although then the nVidia
> rounds it to 520x320mm and ATI to 52x32cm, which is the wrong aspect ratio and
> DPI).
> 
> Apparently, Samsung considers the HDMI port for DVD players only or some such
> and wants to present a 16:9 aspect ratio.
> 
> For some reason though, Windows (XP Media Center) with the ATI card does get it
> right.  Is there a way for Linux to recognize certain bogus EDID results and
> override them?  I'm guessing that must be what Windows does.  It'd be nice if I
> didn't have to buy a new DVI-to-DVI cable just to get this right (it is a
> longer cable than I'm using for testing).

Yes, there is.  Most kinds of EDID quirks we can actually match just by pattern, which takes care of dozens of broken monitors at a stroke, but then we also have a good thirty or so quirks for specific monitors.

xserver 1.5.2 contains a fixup that attempts to recognize monitors (like Robert's) that give their aspect ratio in their "size in cm" field.  Note though that there's two kinds of sizes, a global size and then sizes per mode, and the former is in cm while the latter are in mm.  Best standard ever.

If you're running rawhide (though it looks from your log like you're not), attaching your log from xorg-x11-server 1.5.2-2 or later would probably shed some light on the problem.  I need to build an xserver update for F9 anyway though, so if you'd rather not jump to rawhide yet just wait for the F9 update.

I have been meaning to do a rawhide test install anyway, so I'll give it a spin to get you an updated log.  Mine also is in the "reported size = aspect ratio" (except it reports 16:9 instead of 16:10) category.

Another test might be "crazy high DPI"; the calculated DPI for my monitor with the reported size is over 300 DPI, which I don't think any real-world monitor actually support.

Poking around some more, I'm not sure Windows even uses the EDID reported size values; I think it just always uses 96 DPI for fonts (and then gives you a knob to adjust it).

xorg-x11-server-1.5.2-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-1.fc9

I tried today's rawhide but I got a traceback early in the install.  I did capture the X.log from anaconda.  I did get huge fonts in the first screen though, so I don't think anything has changed for me yet.

Created attachment 320247 [details]
X.log from ATI on rawhide

> (II) RADEON(0): clock: 154.0 MHz   Image Size:  160 x 90 mm

Oh god.  Not only does it lie about size in the global properties but also in the per mode properties.  Someone at samsung needs a stern talking to.

Try 1.5.2-4.fc10 once it's done building, hopefully that'll get the font sizes somewhere closer to right.  I assume "traceback" in comment #9 means from anaconda not from X, since I don't see one in the X log.

The bogus output from comment #11 matches exactly what I recorded back in comment #2 -- the ridiculous size of 16 cm by 9 cm.  And, from what I've read on the net, this is not the first Samsung monitor that was released into the wild with incorrect EDID info.

Created attachment 320370 [details]
X log from 1.5.2-4.fc10

I tried 1.5.2-4.fc10 from koji on my F9 system; still no go.

xorg-x11-server-1.5.2-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8851

Is 1.5.2-1.fc9 have any updates more than 1.5.2-4.fc10 (that doesn't fix my problem) that might fix my problem?  In any case, 1.5.2-1.fc9 is not showing up in updates-testing, so I can't try it.

xorg-x11-server-1.5.2-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-2.fc9

xorg-x11-server-1.5.2-2.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9230

xorg-x11-server-1.5.2-3.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-3.fc9

xorg-x11-server-1.5.2-3.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9380

xorg-x11-server-1.5.2-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.