Logix Monitor: bad EDID reports 4mm x 3mm physical size causing fonts to be mis-sized

Bug #311485 reported by clubsoda
6
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Medium
xorg-server (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-intel

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

Other Details
=============

$lspci
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

$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
name of display: :0.0
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 10502000
X.Org version: 1.5.2
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x1400004, revert to Parent
number of extensions: 31
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    GLX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RANDR
    RECORD
    RENDER
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XC-APPGROUP
    XC-MISC
    XFIXES
    XFree86-DGA
    XFree86-DRI
    XFree86-Misc
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number: 0
number of screens: 1

screen #0:
  dimensions: 1400x1050 pixels (4x3 millimeters)
  resolution: 8890x8890 dots per inch
  depths (7): 24, 1, 4, 8, 15, 16, 32
  root window id: 0x90
  depth of root window: 24 planes
  number of colormaps: minimum 1, maximum 1
  default colormap: 0x20
  default number of colormap cells: 256
  preallocated pixels: black 0, white 16777215
  options: backing-store NO, save-unders NO
  largest cursor: 64x64
  current input event mask: 0x7a802c
    ButtonPressMask ButtonReleaseMask LeaveWindowMask
    ExposureMask StructureNotifyMask SubstructureNotifyMask
    SubstructureRedirectMask FocusChangeMask PropertyChangeMask
  number of visuals: 3
  default visual id: 0x21
  visual:
    visual id: 0x21
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
  visual:
    visual id: 0x22
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
  visual:
    visual id: 0x6a
    class: TrueColor
    depth: 32 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits

Related branches

Revision history for this message
clubsoda (clubsoda) wrote :
Revision history for this message
clubsoda (clubsoda) wrote :
Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Could you tell us what you computer is? Is this an external monitor used on a laptop? Please try using the safe graphics mode (press F4 in the startup screen) and disable desktop effects via System -> Preferences -> Appearance, clicking on "Visual effects" and choosing "None".

Changed in xserver-xorg-video-intel:
status: New → Incomplete
Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

Also, could you add the full output from `lpsci -vvnn`?

Revision history for this message
clubsoda (clubsoda) wrote :

Thanks for following up on this.

First, the good news: The safe mode graphics trick works(!), bringing the system up at 1024x768.
However, normal mode with boot parameter vga=791 fails. Even vga=771 (as suggested in the help pages) fails with enormous panel fonts.

The computer is a desktop with an ASUS P4B533-VM motherboard, Intel 82845G MCH, Intel 82801 ICH4,
512MB DDR memory and integrated Intel "Extreme" graphics.

The working nVidia configuration I mentioned is the exact same box but with an GeForce2 MX400 AGP card driving the monitor. If it helps, I can post that log too.

Does the EDID information from this 1997 model Logix monitor look valid?

Attaching lspci -vvnn as requested.

Cheers.

Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

It seems that you have two separate problems (which of course may have common cause).
1. The resolution is wrong (you want 1280x960, but get 1400x1050)
2. X thinks the physical size of the monitor is 4x3 mm and therefore makes huge fonts to make them have a minimum size in millimeters.

Both may be related to bad EDID information and can probably be overridden in xorg.conf. From your Xorg.0.log it looks like you have some settings in /var/log/xorg.conf. Could you attach that file? Could you also move that file to a different name and log in/out to restart X and see if that makes a difference?

Finally, since parse-edid seems to strip away the information about physical monitor size, could you maybe give the output of `sudo get-edid | hd`. This will show the binary 128 bytes of EDID info in a human readable way. (I haven't had a look at the EDID 1.0 specification yet, but EDID 1.1 seems to be easy to decipher from this format).

Revision history for this message
clubsoda (clubsoda) wrote :

Interesting, I hadn't noticed the 4x3mm problem. I'm sure you're right that this is causing the huge font.

I'm afraid the xorg.conf isn't very exciting - nothing more than the defaults from the Xubuntu Live CD. I will attach it anyway.

Meanwhile, here is the more complete EDID info:-

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 :-]

Revision history for this message
clubsoda (clubsoda) wrote :

OK, I booted up with the BigFont, got back to the console and added the following to the xorg.conf Device section:-
  Option "ModeDebug" "true"
Restarted X and captured the debug log, attached.

Revision history for this message
clubsoda (clubsoda) wrote :

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.

Regards.

Revision history for this message
Geir Ove Myhr (gomyhr) wrote : Re: [Bug 311485] Re: Logix Monitor: Default Resolution Not Valid

I was just reading that document too. It keeps saying "EDID structure
version 1 revision 0 is not considered compliant." (e.g. in section
4.3.2). I guess X assumes the structure that is valid for 1.1 and
above, but I haven't looked at the source code.

Depending on the policy for handling legacy hardware, it may be
possible to add an EDID quirk for this model (see
https://wiki.ubuntu.com/X/Quirks#Monitor%20Quirks). Otherwise, it
should be possible to turn off the DDC information by adding some
lines to the Monitor and Device section of xorg.conf.

Section Device
  ...
  Option "DDC" "false"
EndSection

Section Monitor
  ...
  HorizSync <something>
  VertRefresh <something>
  DisplaySize <x in mm> <y in mm>
EndSection

You can also play with modelines in the device section. The HorizSync
and VertRefresh ranges should be given by your monitor specs.

Revision history for this message
Geir Ove Myhr (gomyhr) wrote : Re: Logix Monitor: Default Resolution Not Valid

It seems like the quirk quirk_detailed_use_maximum_size is made for working around physical size problems like this. This is the description from hw/xfree86/modes/xf86EdidModes.c in the source code for X.org:

    /* Detailed timing descriptors have bogus size values, so just take the
     * maximum size and use that.
     */

The resolution is probably another story.

Geir Ove Myhr (gomyhr)
Changed in xserver-xorg-video-intel:
status: Incomplete → Confirmed
Revision history for this message
clubsoda (clubsoda) wrote :

>The resolution is probably another story.
Yes. I'm regretting the title of this bug report now because I'm no longer worried about the resolution at all. The screen is quite happy at 1400x1050 and even did 1680x1050 when I added these as per your suggestion:-
  HorizSync 30.0-70.0
  VertRefresh 50.0-120.0
  DisplaySize 320 240
Of course, the monitor doesn't have that many physical pixels and thinks those higher modes are 1280x1024 but it's not as if smoke is billowing out the back or anything terrible.
[Those timings were sourced from a Korean page which lists many other Logix monitors too.
http://ftp.narusystem.com/libshop/%EB%8F%84%EC%84%9C%EC%82%AC%EC%97%85/DRIVER/MONITOR/LinuxMon.cfg
In case of a 404 error, Google-> LG-1731D ModeLine <- and click on "View as HTML" to see Google's cache.]

So the real problem is the oversized panel font.
- Option "DDC" "false" works but with limited modes, starting up at only 1152x864.
- Quirks are a good idea but only for monitors we know about.
Moreover, neither of those solutions is available from the kernel boot line (as far as I know), for others who experience this kind of problem.

The VESA document suggests that EDID v1.0, v1.1 and v1.2 should not be trusted with respect to the "detailed timing descriptions" field. If there was a way for the driver to be skeptical about early version EDID but still allow X to come up with exotic timings (which even the manufacturers weren't aware were possible), then that could be ideal.

Thanking you again for your time on this,
Regards.

Revision history for this message
Bryce Harrington (bryce) wrote :

I think this issue should go upstream. Meanwhile, I've written a troubleshooting document about this:
https://wiki.ubuntu.com/X/Troubleshooting/HugeFonts

Changed in xorg-server:
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=22392)
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
....

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=22393)
Xorg.0.Logix.log

Revision history for this message
In , Bryce Harrington (bryce) wrote :

(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.

Revision history for this message
Bryce Harrington (bryce) wrote :

I've forwarded this bug report upstream here:
https://bugs.freedesktop.org/show_bug.cgi?id=19840

Please subscribe to that bug report in case upstream needs further information or wishes you to test something. Thanks ahead of time!

Changed in xorg-server:
status: Unknown → Confirmed
Revision history for this message
In , Julien Cristau (jcristau) wrote :

commit 0660dd9d7009147c395b9ea904539f76f55b9a7f
Author: Adam Jackson <email address hidden>
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.

Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

Upstream reports that the EDID issue has been fixed in xorg-server 1.6.0, which is included in Jaunty. clubsoda, can you verify this by trying a Jaunty LiveCD (alpha3 should be fine, http://cdimage.ubuntu.com/releases/9.04)? There should be a message in Xorg.0.log saying something like "Quirked EDID physical size to XxY cm".

Changed in xorg-server:
status: Confirmed → Fix Released
Revision history for this message
clubsoda (clubsoda) wrote :

A big "Thanks" to everyone here, plus the upstream people who've looked at this.

Unfortunately I'm unable to confirm the fix as yet.
I'm trying the Xubuntu Jaunty Alpha 4 LiveCD i386 ISO from here:-
http://cdimage.ubuntu.com/xubuntu/releases/jaunty/alpha-4/

However, boot fails at the line:-
iTCO_wdt: Found a ICH4 TCO device (Version=1, TCOBASE=0xe460)

The next line which should appear is:-
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
but it hangs instead.
This is just after shpchp is started and just before some ACPI detection. Disabling ACPI and other tricks like safe graphics mode aren't helping. Should I report this somewhere as a bug?

[Incidentally, the xserver version in that ISO is 1.5.99.902. I assume this is for neat numbering in the final release and the code is effectively v1.6.0.]

Cheers.

Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

@clubsoda: you could try using the daily release at http://cdimage.ubuntu.com/xubuntu/daily-live/current/ which are the updated images. If alpha4 is broken for you, perhaps it has already been fixed in the update.

If it is still broken, please report that as a bug, and include in the report that you tried both alpha4 and the daily-live (include the date of this one).

Thanks.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.6.0-0ubuntu1

---------------
xorg-server (2:1.6.0-0ubuntu1) jaunty; urgency=low

  [ Bryce Harrington ]
  * New upstream release
    - Fixes segfault during X startup for drivers with RANDR < 1.2
      (LP: #319210)
    - Fixes EDID for monitors that incorrectly report aspect ratio instead
      of resolution (LP: #311485)
    - Fixes issue where X stops responding to mouse clicks after some time
      if using Xinerama. (LP: #296167)
  * Add 162_null_crtc_in_rotation.patch: Fixes crash when two displays on
    separate cards are attached. X doesn't work with multiple cards yet,
    but crashing is not an appropriate way to handle such a situation.
    (LP: #139990)

  [ Timo Aaltonen ]
  * 159_xinerama_focus.patch,
    161_force_paired_kbd_device.patch:
    - Dropped, applied upstream

 -- Bryce Harrington <email address hidden> Fri, 06 Mar 2009 14:44:31 -0800

Changed in xorg-server:
status: Triaged → Fix Released
Revision history for this message
clubsoda (clubsoda) wrote :

Confirmed fixed on Xubuntu Jaunty Beta. Although the Beta live CD freezes up with a blank screen and no console about half the time, when it does work the old Logix monitor comes up at 1280x960 with sensibly sized panel fonts, yay!

A big thank-you to everyone who helped sort this out.
This bug-fix should keep a few old-style-EDID monitors out of landfill for a little longer.
Group green hug...?
Nobody...?
:)

Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.