Created attachment 22392 [details] BigFont.jpg Forwarding this bug from a Ubuntu reporter: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/311485 [Problem] A Logix LG-1731D monitor has incorrect EDID, causing an incorrect dpi calculating resulting in fonts that are too large. [Original Report] A Logix LG-1731D monitor capable of 1280x960 starts up in 1400x1050 mode. The GUI is unusable due to enormous panel fonts (see attached picture). The attached Xorg.0.log warns of a changed PIPEASTAT register and a failure to allocate texture space. This monitor works fine with an old nVidia card and the nv driver. Cheers. version: Xubuntu 8.10 Intrepid Live CD [lspci] 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) [edid] $sudo get-edid | parse-edid # EDID version 1 revision 0 Section "Monitor" # Block type: 2:0 3:0 # Block type: 2:0 3:0 # Block type: 2:0 3:0 Identifier "OEC:db17" VendorName "OEC" ModelName "OEC:db17" # Block type: 2:0 3:0 # Block type: 2:0 3:0 # Block type: 2:0 3:0 # DPMS capabilities: Active off:yes Suspend:yes Standby:no Mode "640x350" # vfreq 70.072Hz, hfreq 31.462kHz DotClock 25.170000 HTimings 640 656 752 800 VTimings 350 387 389 449 Flags "-HSync" "-VSync" EndMode # Block type: 2:0 3:0 # Block type: 2:0 3:0 # Block type: 2:0 3:0 EndSection $xdpyinfo -display :0 .... screen #0: dimensions: 1400x1050 pixels (4x3 millimeters) resolution: 8890x8890 dots per inch ....
Created attachment 22393 [details] Xorg.0.Logix.log
(The user was able to resolve the resolution problem to his satisfaction. I think there may still be a problem there, but let's focus this bug report just on the invalid EDID for the monitor that causes the large fonts.) Some additional info from the user: get-edid: get-edid version 1.4.1 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0x11110 "Intel(r)845G/845GL/845GE/845GV Graphics Chip Accelerated VGA BIOS" VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call successful 00000000 00 ff ff ff ff ff ff 00 3c a3 db 17 ** ** ** ** |........<.......| 00000010 2a 07 01 00 0c 20 18 00 68 06 92 a0 57 4f 97 26 |*.... ..h...WO.&| 00000020 10 48 4f ff fe 80 31 59 31 68 31 7c 45 59 45 68 |.HO...1Y1h1|EYEh| 00000030 61 59 71 4a 81 40 d5 09 80 a0 20 5e 63 10 10 60 |aYqJ.@.... ^c..`| 00000040 52 08 04 03 00 08 06 18 00 00 00 00 00 00 00 00 |R...............| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 |...............D| 00000080 I found an EDID format description here:- http://faydoc.tripod.com/structures/01/0127.htm I haven't tried to decipher the whole thing but the dimensions of 320x240mm are exactly as reported in the Xorg.0.log. The Modelines in the log look good but maybe the "fuzzy aspect match" is misbehaving(?) (II) intel(0): Using fuzzy aspect match for initial modes (II) intel(0): Output VGA using initial mode 1400x1050 Between the correct probing of screen dimensions and the PIPEASTAT warning, three modules are loaded: fb, exa and ramdac, but ramdac is built-in so that narrows it down to two. Thanks again for looking at this. If you decide it's not worth fixing I won't complain. :) You'll notice I removed the serial# from the EDID, in case I should get a sudden urge to abandon this lumpy CRT by an interstate highway or launch it from a high window. [joke :-] Ah, the 4x3mm mode is coming from the EDID in bytes 0x42 and 0x43 (offset 0c and 0d from 0x36). The monitor claims to be EDID version 1.0. It appears likely that instead of a "detailed timing description", this Logix monitor contains a "manufacturer specific monitor descriptor" in bytes 36h-47h. Further info see page 9 of the following:- http://www.vesa.org/Public/EEDIDguideV1.pdf Perhaps the driver should ignore "detailed timings" for early EDID versions, or at least do a sanity check first. The nv driver must handle this situation differently somehow.
commit 0660dd9d7009147c395b9ea904539f76f55b9a7f Author: Adam Jackson <ajax@redhat.com> Date: Fri Oct 10 13:41:50 2008 -0400 EDID: Catch monitors that encode aspect ratio for physical size. This is not legal in either EDID 1.3 or 1.4, but hey, when did a little thing like legality stop anyone. Feel free to reopen if you can reproduce with server 1.6.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.