DDC report some ridiculous physical screen size - causes wacky font sizes on login screen

[Dave Morley]

Binary package hint: xserver-xorg-video-intel

[Paul: This size 289x21 millimiters is reported by about 6 persons on Intel chipset, I have i945 but
mine is fine]
[Paul: other values seen: 40x30, 10x10 ATI radeon)]

Lure on the kubuntu-devel irc has given me a list of things to report. This report is to fix the following.
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247564230314514
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247581410183714
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247602885020210

The screen res taken from xdpyinfo is
1280x800 pixels (289x21 millimeters)

The dpi taken from xdpyinfo is
112x968 dpi

I will add the log files shortly.

[Update]
This problem is caused by buggy monitors that emit incorrect EDID from their firmware. Fortunately, X.org has a mechanism for working around these bugs, but they're implemented specific to the particular model # of the monitor. So if you find yourself experiencing this problem, please file a NEW bug (don't reopen this one) against xorg-server titled "<monitor-name> produces bad EDID causing large font sizes; needs quirk", and attach the following information:

 * /var/log/Xorg.0.log
 * output from `sudo ddcprobe`
 * output from `sudo get-edid | parse-edid` (you'll need to install the read-edid package)

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
     Subsystem: Hewlett-Packard Company Unknown device [103c:30a5]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA])
     Subsystem: Hewlett-Packard Company Unknown device [103c:30a5]

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=9149)
screenshot of broken kdm screen

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=9150)
used xorg.conf

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=9151)
X log

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=9152)
running xrandr serveral times, one run after another shows different results

[Eric Anholt (eric-anholt)]

OK, we can get that fixed. Can you provide a physical measurement of your panel size (in mm)?

[Arkadiusz Miśkiewicz (arekm)]

DisplaySize 330 210 # mm

these are real values measured manually :)

[Przemyslaw-plewa (przemyslaw-plewa)]

Still doesn’t work witch xserver (1.2.99.903) and intel driver (1.9.93)

[Przemyslaw-plewa (przemyslaw-plewa)]

Still doesn’t work with xserver (1.2.99.903) and intel driver (1.9.94)

[Arkadiusz Miśkiewicz (arekm)]

Unfortunately the problem persist with xserver 1.3.0 and intel driver 2.0.0. Is this issue really so hard? :-)

[Jcnengel (jcnengel)]

*** Bug 10756 has been marked as a duplicate of this bug. ***

[Eric Anholt (eric-anholt)]

Created an attachment (id=11068)
proposed fix for physical size detection

Could you test the attached patch against a current server?

[Przemyslaw-plewa (przemyslaw-plewa)]

Unfortunately the problem persist with xserver 1.3.0 and intel driver 2.1.1 with your patch

[Michael Fu (michael-fu-intel)]

Eric to respond...

[Hong-liu (hong-liu)]

Created an attachment (id=11949)
patch to ry

This patch prefers the user configured DisplaySize to the probed DDC data, please add the actual physical size to your xorg.conf monitor section and have a try.

[agd5f (agd5f)]

(In reply to comment #14)
> Created an attachment (id=11949) [details]
> patch to ry
>
> This patch prefers the user configured DisplaySize to the probed DDC data,
> please add the actual physical size to your xorg.conf monitor section and have
> a try.
>

This patch needs probably go upstream anyway (should go in 1.4.1 as well) as there are often cases when we don't know the physical size of an output and need to specify it. See bug 12474 for example.

[Dave Morley (davmor2)]

Binary package hint: xserver-xorg-video-intel

Lure on the kubuntu-devel irc has given me a list of things to report. This report is to fix the following.
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247564230314514
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247581410183714
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247602885020210

The screen res taken from xdpyinfo is
1280x800 pixels (289x21 millimeters)

The dpi taken from xdpyinfo is
112x968 dpi

I will add the log files shortly.

[Luka Renko (lure)]

You could potentially workaround this issue for at least running KDE session (not for KDM though) by using xrandr in Xsession startup script. You would need to add new file /etc/X11/Xsession.d/35fix-displaysize with the following content:

/usr/bin/xrandr --fbmm 330x210 || true

You need to replace 330x210 with actual size of your display in millimeters (mm).

[Achim Bohnet (allee)]

Or try

       DisplaySize width height
              This optional entry gives the width and height, in millimetres, of the picture area of the monitor. If
              given this is used to calculate the horizontal and vertical pitch (DPI) of the screen.

In the monitor section of xorg.conf. Should work with kdm and kde session.

[Bryce Harrington (bryce)]

I've posted a debdiff with two patches that override the dpi auto-magic in two places:

  http://people.ubuntu.com/~bryce/Testing/xorg-server-dpi/

If it solves the issue, we could investigate doing a cleaner patch.

I'll post an x86 .deb after it's finished building.

[Chi-Thanh Christopher Nguyen (chithanh)]

Created an attachment (id=11987)
Xorg.0.log

Same problem here on Acer 5022 with Mobility Radeon X700, xserver 1.3.0.0 and latest xf86-video-ati from git

[Dave Morley (davmor2)]

Bryce This bug also effects Xubuntu in a similar fashion. As witnessed by Riddell. If you let me know what to do with the file I will apply it and see what happens :)

[Dave Morley (davmor2)]

Bryce that's fixed it :) Login in screen is correct too.

[agd5f (agd5f)]

*** Bug 12784 has been marked as a duplicate of this bug. ***

[Chi-Thanh Christopher Nguyen (chithanh)]

The problem is not caused by the driver, but by bad EDID data from the panel. Bytes 66-67 (image size in mm) are simply copied over from bytes 21-22 (panel size in cm) which is obviously incorrect.

[Eric Anholt (eric-anholt)]

I believe I've fixed the EDID issue upstream now (confused your issue with a very similar one). Please retest.

[agd5f (agd5f)]

*** Bug 12581 has been marked as a duplicate of this bug. ***

[Bryce Harrington (bryce)]

Excellent, I think we should clean up the logic a bit so we don't force the dpi if the user is trying to explicitly override it, but once that's done I think this is ready to commit.

[Chi-Thanh Christopher Nguyen (chithanh)]

Created an attachment (id=12011)
Xorg.0.log

The problem still persists, even with the patch from http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=fc092334ac0a323b80a9602cb8bf60ca9dee3bfa

In Xorg.0.log the EDID quirk is mentioned, but xdpyinfo still shows wrong dpi (and fonts are huge)

[Chi-Thanh Christopher Nguyen (chithanh)]

Created an attachment (id=12012)
xdpyinfo

xdpyinfo output

[Luka Renko (lure)]

This was recently discussed in some xorg bugs:

Intel:
- http://bugs.freedesktop.org/show_bug.cgi?id=10304
ATI:
- http://bugs.freedesktop.org/show_bug.cgi?id=12581
- http://bugs.freedesktop.org/show_bug.cgi?id=12474

Question: does this means that we will be now forced to 96 DPI on all HW (as change is in xserver and not in driver)?

[Luka Renko (lure)]

I have just tested the proposed packages on HP nw8240 with ATI FireGL V5000 (PCIE) with 15.4" (310x210mm), 1920x1200 panel. As expected, this workaround causes that DPI is hardcoded to 96 - xdpyinfo diff:

--- xdpyinfo.before 2007-10-12 22:58:18.000000000 +0200
+++ xdpyinfo.after 2007-10-12 23:37:58.000000000 +0200
@@ -17,7 +17,7 @@
     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 0x2400007, revert to PointerRoot
+focus: window 0x2600007, revert to PointerRoot
 number of extensions: 33
     BIG-REQUESTS
     Composite
@@ -56,8 +56,8 @@
 number of screens: 1

 screen #0:
- dimensions: 1920x1200 pixels (331x207 millimeters)
- resolution: 147x147 dots per inch
+ dimensions: 1920x1200 pixels (507x317 millimeters)
+ resolution: 96x96 dots per inch
   depths (7): 24, 1, 4, 8, 15, 16, 32
   root window id: 0x59
   depth of root window: 24 planes

Side effect of this change is the fact that now fonts are two small - I would need to increase the font size to get some readable font size.
I think this is step back for high-resolution displays (>120 DPI), as they will get fonts (and other UI widgets) smaller then they are defined (in terms of pt).

[Luka Renko (lure)]

I think the proposed quirk solution for buggy EDID as described in FD bug 10304 is more appropriate - it just need to be extended to cover also this particular buggy HW.

[Bryce Harrington (bryce)]

Okay, since this isn't a regression-free fix, let's postpone it for Gutsy-final. When a better, regression-free fix is known, maybe we can push it out as an -update.

[Michael Fu (michael-fu-intel)]

could anybody post a test result of patch in comment# 14?

[Info-aloisnespor (info-aloisnespor)]

(In reply to comment #23)
> could anybody post a test result of patch in comment# 14?
>

Yes, i patch this patcg again Archlinux xorg-server 1.4 :

# Patches from redhat:
  patch -Np3 -i ${startdir}/src/xorg-redhat-die-ugly-pattern-die-die-die.patch
  patch -Np0 -i ${startdir}/src/xorg-x11-server-0.99.3-init-origins-fix.patch
  patch -Np1 -i ${startdir}/src/xorg-x11-server-1.0.1-Red-Hat-extramodes.patch
  patch -Np0 -i ${startdir}/src/xorg-x11-server-1.1.0-no-move-damage.patch
  patch -Np1 -i ${startdir}/src/xorg-x11-server-1.1.1-vbe-filter-less.patch
  patch -Np1 -i ${startdir}/src/xorg-x11-server-1.1.1-no-scanpci.patch
  patch -Np1 -i ${startdir}/src/xserver-1.3.0-newglx-offscreen-pixmaps.patch

  # Own patches
  patch -Np1 -i ${startdir}/src/xorg-server-1.2.0-defaultdpi.patch
  patch -Np1 -i ${startdir}/src/prefer-displaysize.patch

  aclocal
  autoconf
  automake --add-missing
  ./configure --prefix=/usr \
              --with-mesa-source=${startdir}/src/Mesa-${_mesaver} \
              --enable-ipv6 \
              --enable-dri \
              --enable-dmx \
              --enable-xvfb \
              --enable-xnest \
              --enable-composite \
              --enable-xcsecurity \
              --enable-xorg \
              --enable-xtrap \
              --enable-xevie \
       --enable-xephyr \
              --enable-glx-tls \
       --disable-kdrive \
              --enable-install-setuid \
              --disable-xprint \
              --sysconfdir=/etc/X11 \
              --localstatedir=/var \
              --with-default-font-path=/usr/share/fonts/misc,/usr/share/fonts/100dpi:unscaled,/usr/share/fonts/75dpi:unscaled,/usr/share/fonts/TTF,/usr/share/fonts/Type1 \
              --with-rgb-path=/usr/share/X11/rgb \
              --with-xkb-path=/usr/share/X11/xkb \
              --with-xkb-output=/usr/share/X11/xkb/compiled \
              --with-dri-driver-path=/usr/lib/xorg/modules/dri \
              --disable-static

  make || return 1
  make DESTDIR=${startdir}/pkg install || return 1
  mkdir -p ${startdir}/pkg/etc/X11
  mkdir -p ${startdir}/pkg/var/lib
  mv ${startdir}/pkg/usr/share/X11/xkb/compiled ${startdir}/pkg/var/lib/xkb
  ln -sf /var/lib/xkb ${startdir}/pkg/usr/share/X11/xkb/compiled

  cd ${startdir}/pkg/usr/lib/xorg/modules/extensions
  mv libGLcore.so libGLcore.xorg
  mv libglx.so libglx.xorg

  # prevent conflict with nvidia-utils
  mv ${startdir}/pkg/usr/lib/xorg/modules/libwfb.so \
     ${startdir}/pkg/usr/lib/xorg/modules/libwfb.so.1.4
-------------------------------------------------------------

ARCH x86_64

kernel 2.6.23
dbus 1.1.2
hal 0.5.10
xf86-video-intel 2.1.1
xorg 1.4
GCC 4.2.2
pixman 0.9.5
-----------------------------------------------------------------

Result: X server not starting, crash!

Backtrace:
0: X(xf86SigHandler+0x6a) [0x48d0ba]
1: /lib/libc.so.6 [0x2b8cc69517b0]
2: X(xf86RandR12CreateScreenResources+0x1ee) [0x4b2a5e]
3: X [0x4ada9f]
4: X(main+0x319) [0x4367d9]
5: /lib/libc.so.6(__libc_start_main+0xf4) [0x2b8cc693eae4]
6: X(FontFileCompleteXLFD+0x261) [0x435c79]

Fatal server error:
Caught signal 11. Server aborting

please see Xorg.0.log - DPI is not anyway (96,96) , b...

[Info-aloisnespor (info-aloisnespor)]

Created an attachment (id=12171)
crashed xorg-server 1.4

[Info-aloisnespor (info-aloisnespor)]

Created an attachment (id=12172)
crashed xorg-server 1.4 log

crashed xorg-server 1.4 log

[Arkadiusz Miśkiewicz (arekm)]

Confirming.

We tested #14 when it appeared but the server crashed. Unfortunately we had no debug symbols compiled in so we weren't able to dig deeper what's the cause. Now I see that the patch was problematic as crash happens for others, too.

[Sndirsch-suse (sndirsch-suse)]

Looks like you're not using a monitor section at all or do not specify it properly with

  Option "Monitor-outputname" "monitorsection"

Still it's a bug in the patch of comment #14, since you get a Nullpointer
reference when not using a monitor section. This should not happen. I stumbled
across this today as well ...

Better version of this patch:

diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 38435c9..135356d 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -426,8 +426,18 @@ xf86RandR12CreateScreenResources (ScreenPtr pScreen)
            xf86OutputPtr output = config->output[config->compat_output];
            xf86CrtcPtr crtc = output->crtc;

- if (crtc && crtc->mode.HDisplay &&
- output->mm_width && output->mm_height)
+ if (output->conf_monitor &&
+ (output->conf_monitor->mon_width > 0 ||
+ output->conf_monitor->mon_height > 0))
+ {
+ /*
+ * Prefer user configured DisplaySize
+ */
+ mmWidth = output->conf_monitor->mon_width;
+ mmHeight = output->conf_monitor->mon_height;
+ }
+ else if (crtc && crtc->mode.HDisplay &&
+ output->mm_width && output->mm_height)
            {
                /*
                 * If the output has a mode and a declared size, use that

[Mhopf-suse (mhopf-suse)]

I committed a slightly modified version of this patch (a monitor section with either width or height <= 0 shouldn't be honored as well).
But I think the original issue is still open.

[Info-aloisnespor (info-aloisnespor)]

(In reply to comment #29)

it's a good thing, thanks! Xserver not crashed.

-------------------------------------------------------------------------------
I use new add (for my laptop) in xorg.conf for Option "Monitor-outputname" "monitorsection" :

Section "Monitor"
        Identifier "LCD 1280x800"
        Option "DPMS" "true"
 VendorName "LPL"
 DisplaySize 338 211
 Option "Monitor-LVDS " "LVDS monitor"
EndSection
-------------------------------------------------------------------------------

Results : xserver 1.4 with "better" patch set display dimensions now right :
(**) intel(0): Display dimensions: (338, 211) mm

but DPI is set wrong - DPI is now 96,154.

[Info-aloisnespor (info-aloisnespor)]

Created an attachment (id=12180)
better patch - xserver works ( Xorg.0.log)

[agd5f (agd5f)]

(In reply to comment #30)
>
> Results : xserver 1.4 with "better" patch set display dimensions now right :
> (**) intel(0): Display dimensions: (338, 211) mm
>
> but DPI is set wrong - DPI is now 96,154.
>

check xdpyinfo. you dpi should be correct. the (**) intel(0): DPI set to (96, 154) line is misleading in that it takes into account the virtual size of the desktop when it prints that. The xrandr code does the right thing however.

[Info-aloisnespor (info-aloisnespor)]

(In reply to comment #32)

OK, results from xdpyinfo:

# xdpyinfo |grep resolution
 resolution: 112x968 dots per inch

the font is huge

---------------------------------------------------------

when i use # xrandr --fbmm 338x211 : (338x211 is physical size of my laptop´s display)

# xdpyinfo |grep resolution
  resolution: 96x96 dots per inch
the font is correct

[Sndirsch-suse (sndirsch-suse)]

>Section "Monitor"
> Identifier "LCD 1280x800"
> Option "DPMS" "true"
> VendorName "LPL"
> DisplaySize 338 211
> Option "Monitor-LVDS " "LVDS monitor"
>EndSection
Isn't the monitor Option line just wrong? Shouldn't this be

  Option "monitor-LVDS " "LCD 1280x800"

instead?

[Info-aloisnespor (info-aloisnespor)]

(In reply to comment #34)
> >Section "Monitor"
> > Identifier "LCD 1280x800"
> > Option "DPMS" "true"
> > VendorName "LPL"
> > DisplaySize 338 211
> > Option "Monitor-LVDS " "LVDS monitor"
> >EndSection
> Isn't the monitor Option line just wrong? Shouldn't this be
>
> Option "monitor-LVDS " "LCD 1280x800"
>
> instead?
>

Yes, right !! I am idiot, sorry.

If i use "better" patch + in xorg.conf DisplaySize + Option "Monitor-outputname" "monitorsection" the dpi is correct !! 96dpi, no huge wrong DPI.

The problem is fixed.

Can another make test for confirmation?

[Info-aloisnespor (info-aloisnespor)]

Created an attachment (id=12190)
xorg.conf with right set DisplaySize and "Monitor-outputname" "monitorsection"

[Info-aloisnespor (info-aloisnespor)]

Created an attachment (id=12191)
xdpyinfo with fixed DPI

[Sndirsch-suse (sndirsch-suse)]

Since Matthias pushed the fix upstream, let's finally close this one as fixed.

[Info-aloisnespor (info-aloisnespor)]

Thanks to all !

[Jere Kupari (jere-kupari)]

I have an ubuntu-kubuntu-xubuntu amd64 and radeon 9600 ("ati"-driver), and I'm using gdm.

Updated to gutsy.
Login screen was ok. But my kde and xfce were totally useless for this bug.
Logging to KDE, kdesktop and xorg would use hundreds of megabytes each, quite some swapping... Also the fonts were huge.

xfce seemed to work ok, but the screensized fonts made it unusable.

One time also gnome got these huge-font issues in firefox and thunderbird.
And gnome panel always flashed as five times it's size at the start. Then went immediately to normal.

I had
$ xdpyinfo | grep [0-9][0-9]x[0-9][0-9]
  dimensions: 1024x768 pixels (1x257 millimeters)
  resolution: 26010x76 dots per inch
  largest cursor: 64x64
$ grep DPI /var/log/Xorg.0.log
(**) RADEON(0): DPI set to (137, 132)
$ xrdb -query | grep dpi
Xft.dpi: 96.000000

Adding
 DisplaySize 310 230
to xorg.conf didn't change anything.

But the /etc/X11/Xsession.d/35fix-displaysize fixed these issues.
$ xdpyinfo | grep [0-9][0-9]x[0-9][0-9]
  dimensions: 1024x768 pixels (310x230 millimeters)
  resolution: 84x85 dots per inch
  largest cursor: 64x64

I'm still having a lot of irregular lock-ups, but that probably is another issue.

[JBraud (jon-afksolutions)]

I have a similar problem, my login screen fonts are very big but no other fonts are affected, spash screen, desktop etc.

I'm using an Intel 810. Let me know if you want any logs.

[molnarcs (csabamolnar)]

I managed to solve this problem by adding -dpi 100 argument to X in kdmrc (ServerCmd=/usr/bin/X -br -dpi 100). This drove me crazy btw. Details:
http://kubuntuforums.net/forums/index.php?topic=3087975.0

[xhantt (xhantt)]

Other solution is to add the line

Option "DDC" "No"

to intel Device section of /etc/X11/xorg.conf.

I've read from a Mandriva/Suse forum this, but I don't have the link handy.

[Paul Dufresne (paulduf)]

I believe bug #107320, and it's 4 duplicates, are duplicates of this one.

[Paul Dufresne (paulduf)]

First, this bug seems to have been 'Fix commited' (they call this Resolved) in X.org project, according to:
https://bugs.freedesktop.org/show_bug.cgi?id=10304

Second, according to puccha, Option "DDC" "no", resolve also the following problems:
mythtv (video and live tv where squized)
compiz-fusion (would boot up with HUGE titlebars)
teamspeak (menu scaling was incorrect to the point it was unuseable.)
I'll try to find these bug, and possibly mark them duplicates of this one if the report bad physical dimensions.

Third, for ATI driver extract from Laurent:
I have backported the debian version of xserver-xorg-video-ati(6.6.3-2) to gutsy and I don't have this issue, should be introduced by some ubuntu patch

[Paul Dufresne (paulduf)]

Well, as I understand here, the heart of the problem is:
"The problem is not caused by the driver, but by bad EDID data from the panel.
Bytes 66-67 (image size in mm) are simply copied over from bytes 21-22 (panel
size in cm) which is obviously incorrect." according to:
https://bugs.freedesktop.org/show_bug.cgi?id=10304#c18

This can be better understood by reading EDID 1,1 data format at:
http://en.wikipedia.org/wiki/Extended_display_identification_data

Should be fix upstream of X.org (I suppose EDID is some kind of module project for Xorg).

Rest of https://bugs.freedesktop.org/show_bug.cgi?id=10304, seems to be related to the fact that specifying display size in xorg.conf was not working.
So someone have given a patch in comment #14, but it was buggy, but with some patch to the patch, was finally fixed.

So the question is mostly, when and how it will be introduce in Hardy (if it is not already the case).
And to see if it fix it for everyone.

[Paul Dufresne (paulduf)]

Eh... reading again, I come to the conclusion that bug #10304 is fixing only for the following monitor model:
/* Bug #10304: "LGPhilipsLCD LP154W01-A5" */ as I can read by reading the patch:
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blobdiff;h=9fa5fef9e3566cc2344f5e10c0b1fa9ed1b54c9b;hp=8b5e69d9a5fea419ecb487f2314f5ecc1a14e429;hb=fc092334ac0a323b80a9602cb8bf60ca9dee3bfa;f=hw/xfree86/modes/xf86EdidModes.c

Eh... Are you all using this monitor? (Half joking)

[xhantt (xhantt)]

No exactly the same but close LGPhilipsLCD LP154W01-TLA2, please for more details see attachment with EDID output.

[Paul Dufresne (paulduf)]

Actually, the current patch looks for:
DDC->vendor.name, "LPL" and
DDC->vendor.prod_id == 0
xhantt, your log gives (II) intel(0): Manufacturer: LPL Model: 0 Serial#: 0
so it should be covered (supposing Model is the same as prod_id).

I would have to check others people Xorg.log files to see if they fit in too.
Anyway, upstream patch make it very easy to add new broken monitor models.

[Paul Dufresne (paulduf)]

Covered:
Maciej,bug #107320, (II) intel(0): EDID vendor "LPL", prod id 0
gutocarvalho,bug #107320,(II) intel(0): Manufacturer: LPL Model: 0 Serial#: 0
Paresh ,bug #107320,(II) intel(0): Manufacturer: LPL Model: 0 Serial#: 0

Not covered:
servaas-xubuntu-user, bug #127827, (II) intel(0): Manufacturer: LPL Model: 2a00 Serial#: 0 (near miss!)
Matt, bug #107320, (II) RADEON(0): Manufacturer: DMI Model: 0 Serial#: 66
note about Matt: (II) RADEON(0): EDID data from the display on port 1 (may have 2 displays? don't find port 2)
Etienne, bug #107320, (II) RADEON(0): Manufacturer: TRL Model: 610 Serial#: 5989
Tcl70, bug #120480,(II) RADEON(0): Manufacturer: @HA Model: 101 Serial#: 16843009

Unknown:
nzk, bug #91042, no Xorg.0.log file
Mathew Nuzum, bug #107320, no log file
olo, bug #107320, no log file
puccha, bug #107320, no log file
zadkiel, bug #127827, no log
Caleb Cupples, bug #128146, no Xorg.0.log file
davmor2, bug #128146, no log file
tenco, bug #152332, no log file

[Paul Dufresne (paulduf)]

Sorry, missed this bug. :-)

Not covered:
davmor, bug #151311, (II) intel(0): Manufacturer: LPL Model: 2a00 Serial#: 0 (near miss)

[Paul Dufresne (paulduf)]

Here on Ubuntu we have the bug:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/107320

It seems we have someone with a similar but not identical monitor.

servaas-xubuntu-user, bug #127827
(II) intel(0): Manufacturer: LPL Model: 2a00 Serial#: 0 (near miss!)
(II) intel(0): Setting screen physical size to 289 x 21
servaas-xubuntu-user (Problem in XUbuntu in general, not just GDM)
X Window System Version 1.3.0
X Protocol Version 11, Revision 0, Release 1.3
Current Operating System: Linux ubuntu 2.6.22-8-generic #1 SMP Thu Jul 12 15:59:45 GMT 2007 i686
(==) intel(0): DPI set to (75, 75)

His bug is reported in Ubuntu at:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/127827
and it's Xorg.0.log file is at:
http://launchpadlibrarian.net/8675708/Xorg.0.log

My believe is that the patch should be modified to add this monitor model (2a00).

We also have 1 person with detected 40x30 mm screen, and one with 10mmx10mm screen. I don't think they are related to this bug, but if curious more info is at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/151311/comments/29

[Paul Dufresne (paulduf)]

Expanding information for not covered people:

servaas-xubuntu-user, bug #127827, (II) intel(0): Manufacturer: LPL Model: 2a00 Serial#: 0 (near miss!)
(II) intel(0): Setting screen physical size to 289 x 21 (Height divided by 10)
servaas-xubuntu-user (Problem in XUbuntu in general, not just GDM)
X Window System Version 1.3.0
X Protocol Version 11, Revision 0, Release 1.3
Current Operating System: Linux ubuntu 2.6.22-8-generic #1 SMP Thu Jul 12 15:59:45 GMT 2007 i686
(==) intel(0): DPI set to (75, 75)

Matt, bug #107320, (II) RADEON(0): Manufacturer: DMI Model: 0 Serial#: 66
(--) fglrx(0): Display dimensions: (40, 30) mm (??? both divided by 10 ????????)
(--) fglrx(0): DPI set to (812, 866)
X Window System Version 7.2.0
X Protocol Version 11, Revision 0, Release 7.2
Current Operating System: Linux matt-desktop 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686
http://launchpadlibrarian.net/9292633/Xorg.0.log.ubuntu
(II) fglrx(0): Display1 EDID data ---------------------------
(II) fglrx(0): Manufacturer: DMI Model: 0 Serial#: 66
(II) fglrx(0): Year: 2004 Week: 17
(II) fglrx(0): EDID Version: 1.0
(II) fglrx(0): Digital Display Input
(II) fglrx(0): Max H-Image Size [cm]: horiz.: 4 vert.: 3
(II) fglrx(0): Gamma: 2.56
(II) fglrx(0): DPMS capabilities: StandBy; RGB/Color Display
(II) fglrx(0): Default color space is primary color space
(II) fglrx(0): First detailed timing is preferred mode
(II) fglrx(0): redX: 0.000 redY: 0.000 greenX: 0.000 greenY: 0.000
(II) fglrx(0): blueX: 0.000 blueY: 0.000 whiteX: 0.000 whiteY: 0.000
...
(II) fglrx(0): Manufacturer's mask: 78
(II) fglrx(0): Supported Future Video Modes:
(II) fglrx(0): #0: hsize: 1280 vsize 720 refresh: 60 vid: 49281
(II) fglrx(0): #1: hsize: 1280 vsize 720 refresh: 60 vid: 49281
(II) fglrx(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897
(II) fglrx(0): Supported additional Video Mode:
(II) fglrx(0): clock: 108.0 MHz Image Size: 4 x 3 mm
(II) fglrx(0): h_active: 1280 h_sync: 1528 h_sync_end 1640 h_blank_end 1688 h_border: 0
(II) fglrx(0): v_active: 1024 v_sync: 1062 v_sync_end 1065 v_blanking: 1066 v_border: 0
(II) fglrx(0): Stereo: left channel on sync
side-by-side interleaved(II) fglrx(0): EDID (in hex):
(II) fglrx(0): 00ffffffffffff0011a9000042000000
(II) fglrx(0): 110e01009804039c8e00000000000000
(II) fglrx(0): 000000fffff881c081c0818000000000
(II) fglrx(0): 000000000000000000fc004c4344204d
(II) fglrx(0): 756c74692d4d6564000000fc00696120
(II) fglrx(0): 446973706c6179202020000000fc000a
(II) fglrx(0): 202020202020202020202020302a0098
(II) fglrx(0): 51002a40f870630804030000007800ca
(II) fglrx(0): End of Display1 EDID data --------------------

Etienne, bug #107320, (II) RADEON(0): Manufacturer: TRL Model: 610 Serial#: 5989
(II) RADEON(0): Setting screen physical size to 4 x 3 (??? both divided by 10 ???)
(**) RADEON(0): Display dimensions: (320, 240) mm
(**) RADEON(0): DPI set to (101, 108)
X Window System Version 1.3.0
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Linux Ubuntu (xorg-server 2:1.3.0.0.dfsg-12ubuntu6)
Current Operating System: Linux etienne-desktop 2.6.22-12-generic #1 SMP Sun Sep 23 18:11:30 GMT 2007 i686
...

[anespor (alois-nespor-gmail)]

Hello guys!

First sorry of my bad english.

This problem is fixed in the Xorg xserver 1.4.1 (comming soon).
- "Option" "DDC" "Off" is really not solution
- Displaysize is first part of solution.

Complet solution of this problem is:

xorg-server 1.4.1 + Xrandr 1.2.2+ (and maybe new xf86-video-intel 2.2 driver) and right set xorg.conf

Section "Monitor"
        Identifier "LCD 1280x800"
        Option "DPMS" "true"
 VendorName "LPL"
 DisplaySize 338 211 # first part solution
 Option "Monitor-LVDS" "LCD 1280x800 # second part solution <- option for Xrandr (see: man xrandr)
EndSection

I test it for Intel 945GM and works fine

Regards,
Alois Nespor
reporter and tester
distro Archlinux x86_64

[Paul Dufresne (paulduf)]

Anespor, could you attach your /var/log/Xorg.0.log file?
The fact that you have to edit your /etc/X11/xorg.conf file suggest to me that you don't have a model:0 of LPL.

[anespor (alois-nespor-gmail)]

Hi, i send Xorg.0.log.

You need edit xorg.conf and patch for xserver 1.4 ( i have patch on my xorg-xserver ). Archlinux's xorg-server it has not.

[Tormod Volden (tormodvolden)]

Just to sum up the status of some bug fixes which have been mentioned:

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=fc092334ac0a323b80a9602cb8bf60ca9dee3bfa
This commit adds quirks for some monitor models, so that the probed EDID info will be corrected. It will be included in xorg-server 1.5.

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=fc092334ac0a323b80a9602cb8bf60ca9dee3bfa
This commit fixes the "DisplaySize" option so that it will always override any probed EDID info and be used to calculate DPI correctly. This one will be in xorg-server 1.4.1 (and is already in Hardy). The fix might be considered for backporting to the 1.3 in Gutsy.

[Danilo Piazzalunga (danilopiazza)]

I am affected by this bug too, with an Intel 915GM on a Toshiba laptop.
Here is my Xorg.0.log, collected on a Gutsy installation.
It looks like the model is the same which has been already reported above, but I am attaching this "just in case". Currently I am using the -dpi option as a workaround.

[PJSingh5000 (pjsingh5000)]

Anespor's suggestion works well. Add the following two lines to the "Monitor" section of xorg.conf:

 DisplaySize <WIDTH in mm> <HEIGHT in mm>
 Option "Monitor-LVDS" "<Monitor Identifier>"
 # Replace the <...> with your own values

Here is the full "Monitor" section from my updated xorg.conf for your reference...

Section "Monitor"
        Identifier "DCLCD"
        Option "DPMS" "true"
        HorizSync 64.7-65.29
        VertRefresh 59.883-59.954
        DisplaySize 433 271
        Option "Monitor-LVDS" "DCLCD"
EndSection

[Mhopf-suse (mhopf-suse)]

*** Bug 13458 has been marked as a duplicate of this bug. ***

[Tormod Volden (tormodvolden)]

The line
 Option "Monitor-LVDS" "<Monitor Identifier>"
belongs to the Device section. I guess it will work anyway ATM, but it doesn't look logical when it's somewhere else.

[PJSingh5000 (pjsingh5000)]

Thanks for the clarification, Tormod's.

Add the following line to the "Device" section of xorg.conf:
    Option "Monitor-LVDS" "<Monitor Identifier>"

Then add the following line to the "Monitor" section of xorg.conf:
    DisplaySize <WIDTH in mm> <HEIGHT in mm>

Replace the <...> with your own values.

Here is an example...

Section "Device"
    Identifier "Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller"
    Driver "intel"
    BusID "PCI:0:2:0"
    Option "monitor-LVDS" "DCLCD"
EndSection

Section "Monitor"
    Identifier "DCLCD"
    Option "DPMS" "true"
    HorizSync 64.7-65.29
    VertRefresh 59.883-59.954
    DisplaySize 433 271
EndSection

[PJSingh5000 (pjsingh5000)]

I think The X Resize and Rotate Extension (RandR) is getting confused between multiple monitors, when the chipset is dual-head capable, and multiple monitors are not present. Here is an xorg.conf solution/work-around that is working very well for me so far. This also fixes the font size and resolution problems in both KDM and the user's X Session.

PART A - Collect Information
----------------------------

Step 1: At the terminal, enter xrandr.

Here is an example of the output...

$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1680 x 1680
VGA disconnected (normal left inverted right)
LVDS connected 1024x768+0+0 (normal left inverted right) 0mm x 0mm
   1024x768 60.0*+ 85.0 75.0 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 72.8 75.0 59.9
   720x400 85.0
   640x400 85.1
   640x350 85.1
TMDS-1 connected 1024x768+0+0 (normal left inverted right) 433mm x 270mm
   1680x1050 59.9 + 60.0
   1280x1024 75.0 59.9
   1440x900 59.9
   1280x960 59.9
   1360x765 59.8
   1280x800 59.8
   1152x864 75.0 60.0
   1280x720 59.9
   1024x768 75.1* 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 75.0 72.8 66.7 60.0
   720x400 70.1
TV disconnected (normal left inverted right)
$

Notice that there are two monitors that are active (LVDS and TMDS-1). The current resolution of each monitor is indicated by an "*". LVDS is typically a laptop screen, and TMDS-1 is typically your 1st DVI monitor.

The current resolution on LVDS has been set to its preferred resolution of 1024x768, indicated by "+" in the LVDS section of the xrandr output. It seems that the current resolution of TMDS-1 has *also* been set to the preferred resolution of LVDS (i.e. 1024x768)! However the preferred resolution for TMDS-1 is actually 1680x1050, as indicated by the "+" in the TMDS-1 section above.

As a result, the output of the DVI monitor will be at 1024x768 instead of 1680x1050.

You could use the following command to select the desired resolution after logging in each time, but this is a manual fix that does not address the KDM resolution issue:
    $xrandr -s 1680x1050

A more elegant solution can be achieved if you do not have one of the listed monitors. For example, my system has a DVI monotor (TMDS-1) and no laptop screen (LVDS). The problem is that the current resolution on the DVI monitor (TMDS-1) is being set to the preferred resolution of the non-existent laptop screen (LVDS).

PART B - Edit xorg.conf
-----------------------

Make the following changes to xorg.conf...

Step 1: Create a "Monitor" section for the existing monitor (listed in the xrandr output).
Step 2: Create a "Monitor" section for the non-existent monitor (listed in the xrandr output).
Step 3: For the non-existent monitor, add the Option "Ignore" "true".
Step 4: Associate the existing monitor with the "Device" so it can be used.
        Remember to PREFIX the monitor name from the xrandr output with "monitor-".
Step 5: Associate t...

[Paul Dufresne (paulduf)]

PJSingh5000, this previous comment seems to be an other bug to me.
I suggest you open a new bug and that you copy the bug number here in a new comment.
Please note that xrandr have an ---output parameter. (man xrandr)

I am quite lost as the status of this bug.

upstream bug 10304 is resolved, which means that the product it is in have not been released (then it would be closed),
but also that it has not been verified by QA (don't know if I can really expect it to be verified by QA).

I am on hardy and when I do:
paul@Arcturus:~$ dpkg -l |grep xserver-xorg-core
ii xserver-xorg-core 2:1.4.1~git20080105-1ubuntu1 Xorg X server - core server
paul@Arcturus:~$

I come to conclusion that maybe all the new quirks are now inside hardy. (since the version coming from git version control system rather than a released version).
So, my understanding is that for most people, Hardy should work fine, even if we rename xorg.conf in xorg.old having no xorg.conf file.
But I am really not sure of that!

The Hardy Heron Alpha series was recently released. Alpha2 and subsequent releases contain an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . Please note that Alpha3 will be released today or tomorrow so you many want to wait. You should be able to then test this bug with the new kernel on the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

Thanks!

[PJSingh5000 (pjsingh5000)]

Paul,

Thanks for your suggestion. Perhaps I will try Alpha 3.

Thanks,

PJ Singh

On Jan 10, 2008 12:52 PM, Paul Dufresne <email address hidden> wrote:

> PJSingh5000, this previous comment seems to be an other bug to me.
> I suggest you open a new bug and that you copy the bug number here in a
> new comment.
> Please note that xrandr have an ---output parameter. (man xrandr)
>
> I am quite lost as the status of this bug.
>
> upstream bug 10304 is resolved, which means that the product it is in have
> not been released (then it would be closed),
> but also that it has not been verified by QA (don't know if I can really
> expect it to be verified by QA).
>
> I am on hardy and when I do:
> paul@Arcturus:~$ dpkg -l |grep xserver-xorg-core
> ii xserver-xorg-core 2:1.4.1~git20080105-1ubuntu1 Xorg X server - core server
> paul@Arcturus:~$
>
> I come to conclusion that maybe all the new quirks are now inside hardy.
> (since the version coming from git version control system rather than a
> released version).
> So, my understanding is that for most people, Hardy should work fine, even
> if we rename xorg.conf in xorg.old having no xorg.conf file.
> But I am really not sure of that!
>
> The Hardy Heron Alpha series was recently released. Alpha2 and
> subsequent releases contain an updated version of the kernel. You can
> download and try the new Hardy Heron Alpha release from
> http://cdimage.ubuntu.com/releases/hardy/ . Please note that Alpha3
> will be released today or tomorrow so you many want to wait. You should
> be able to then test this bug with the new kernel on the LiveCD. If you
> can, please verify if this bug still exists or not and report back your
> results. General information regarding the release can also be found
> here: http://www.ubuntu.com/testing/ .
>
> Thanks!
>
> --
> DDC report some ridiculous physical screen size (Mostly on Intel driver,
> and some ATI)
> https://bugs.launchpad.net/bugs/151311
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[JLK (jlk)]

I have the same problem with a fresh install of Kubuntu Hardy Alpha 3. My computer is a Fujitsu laptop with i945GM video.

kdm shows very very big fonts at login. After logging, the rest of kde looks OK.

I tried adding a DisplaySize line in xorg.conf, without success.

[anespor (alois-nespor-gmail)]

@ Jacques-Louis KREISS :

you must right set your Xorg.conf :

Add the following line to the "Device" section of xorg.conf:
    Option "Monitor-LVDS" "<Monitor Identifier>"

Then add the following line to the "Monitor" section of xorg.conf:
    DisplaySize <WIDTH in mm> <HEIGHT in mm>

Replace the <...> with your own values.

Here is an example...

Section "Device"
    Identifier "Intel Corporation Mobile GM945 Integrated Graphics Controller"
    Driver "intel"
    BusID "PCI:0:2:0"
    Option "monitor-LVDS" "DCLCD"
EndSection

Works fine that way ...

Section "Monitor"
    Identifier "DCLCD"
    Option "DPMS" "true"
    HorizSync 64.7-65.29
    VertRefresh 59.883-59.954
    DisplaySize 433 271
EndSection

[PJSingh5000 (pjsingh5000)]

Jacques-Louis KREISS,

At the command line, please run:
    $ xrandr

Please paste the output here.

(I tried Hardy Alpha 3 very briefly, and the login screen resolution was not overly large as it was with Gusty. Unfortunately, I did not check to see if the login screen resolution was inconsistent with the preferred resolution of my monitor).

[JLK (jlk)]

@ PJSingh5000

Here is the output of xrandr:

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 289mm x 21mm
   1280x800 60.1*+ 60.0
   1280x768 60.0
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TV disconnected (normal left inverted right x axis y axis)

[Paul Dufresne (paulduf)]

>289mm x 21mm
Jacques, could you attached /var/log/Xorg.0.log file, please?

[JLK (jlk)]

Hi Paul,

Thanks for your help. Find my Xorg.0.log attached...

[Paul Dufresne (paulduf)]

Jacues have (II) intel(0): EDID "vendor "LPL", prod id 0" in Xorg.0.log for following version:
Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080105-1ubuntu1)
Current Operating System: Linux jack-laptop 2.6.24-4-generic #1 SMP Mon Jan 14 17:30:39 UTC 2008 i686
Build Date: 08 January 2008 07:42:40PM

That model is the one that should have been patched.
I did not found the work 'quirk' in his log.

Well, it looks like the patch is not yet integrated but I don't understand why.

[Tormod Volden (tormodvolden)]

The quirk patch was committed to the upstream git head (to become 1.5) but might not be in the 1.4 branch that Hardy is tracking. Only selected fixes from the git head ("master") are ported to the 1.4 branch, see http://wiki.x.org/wiki/Server14Branch

Just correcting the links from my earlier post:

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=fc092334ac0a323b80a9602cb8bf60ca9dee3bfa
This commit adds quirks for some monitor models, so that the probed EDID info will be corrected. It will be included in xorg-server 1.5.

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=feac0759522cbdc3e61ccfa373df735903c5cb27
This commit fixes the "DisplaySize" option so that it will always override any probed EDID info and be used to calculate DPI correctly. This one will be in xorg-server 1.4.1 (and is already in Hardy).

[Bryce Harrington (bryce)]

Thanks for doing all the legwork on this one Paul. The patch looks good and builds properly. I've committed it to Ubuntu's xorg-server git tree for upload.

Also thanks for flagging related issues *not* solved by this patch; I've assigned them to myself and will take a look when I get a chance. Sounds like we just need to build more quirks for those as well.

[Bryce Harrington (bryce)]

Released in yesterday's upload of -intel.

[JLK (jlk)]

Hi there,

I still have the same problem with Hardy Alpha 5 and the latest updates.
Find my Xorg.0.log attached.

[Jimmygoon (jimmygoon)]

Despite what the comments here imply.
My intel driver is very much ignoring Option "DisplaySize" still and is making the fonts far too large. I am completely up to date with my Hardy upgrades.

Thanks.

[Jimmygoon (jimmygoon)]

To give some more information:
I got it working with the correct DisplaySize and I seemed to have gotten it to where the dpi was correct but good god was it slow. I've never seen firefox render anything quite so slowly or a simple picture to load. I was watching it as it scanned from top to bottom...

So, I'm not sure what's going on now. I guess I'll wait. I've spent about two hours trying to get something working to no avail. I'm just reverting back to i810 for now.

[xhantt (xhantt)]

Hi Jimmygoon,

Which is the model of your card? it may be helpful for other people that are trying to install Hardy.

As stated previously some monitors report a buggy EDID, in order to fix for you monitor it wil be helpful to provide your /var/log/Xorg.0.log file?

If the intel driver is too slow I'll suggest to open another bug report, well it doesn't seems to be related to this bug.

[Jimmygoon (jimmygoon)]

Sorry, I admit I was a bit frustrated earlier and was a tad unwilling to spend much more time with this bug, but today I'm more geared up.

I've attachment my Xorg.0.log. This is basically a result what ubuntu sets up EXCEPT for when I specify the 'i810' driver (like I've stated ubuntu defaults to 'intel'). My graphics card is: Intel Integrated 855GM (Intel(r)852GM/852GME/855GM/855GME)

I think I managed to get it working by specifying DisplaySize but... it was strange. It cause gnome-settings-daemon to crash (every single time and starting it from CLI gave a core segfault) and so it may have been a combination of things leading to a sluggish feel that I was attributing to the intel driver.

So basically, my workaround stands for me of switching back to i810 (I keep saying this in case someone else sees this with the same problem :D)

If someone wants, I'll be around #ubuntu+1 for basically... all day today and most of tomorrow so I can try things at will. I've got another computer so I can get on IRC there and test stuff here and go through different test scenarios if that would be helpful.

[Jimmygoon (jimmygoon)]

Attached are the Xorg.0.logs for
1st - using the 'intel' driver with no adjustments
2nd - using the 'intel' driver plus doing the following: (this log is included in the next post... only one attachment at a time)

* Setting DisplaySize for my Monitor
* Adding the Option "Monitor-LVDS" "Configured Monitor" to my xorg.conf

I don't know why, but those two things APPEARS to get the fonts right (presumably with the intel driver) on my GDM screen and I'm about to check and see if gnome-settings-daemon survives.
How can I check and make sure intel is in use and I'm not wasting my time debugging VESA kicking in? thanks.

Yep, gnome-settings-daemon crashes upon attempt to login ---- "The Settings Daemon restarted too many times"
Attempting to run "gnome-settings-daemon" as superuser from the CLI gives: http://paste.ubuntu-nl.org/59867/

Finally, I'm afraid there is some sort of bug overlap. After implementing the fixes I've described here, I tried to submit a bug report for the gnome-settings-daemon and came across this:
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/197153
(Note the last comment before mine... describing how that person was suffering this bug on an Intel 855 GM chipset (same as mine)

I hope this is making forward progress. Thanks so much!

[Jimmygoon (jimmygoon)]

(attached is the xorg.0.log file for all of my above described changes)
edid/display size + lvds

[Jimmygoon (jimmygoon)]

I hope this isn't annoying my four posts in a row... but I like to think I'm hopefully giving helpful beneficial information.

The crashing of gnome-settings-daemon appears to be that other bug I referenced above and after implementing the workaround I have the intel driver working (after a whole bug of mangling with xorg.conf though) with the right resolution and dpi.

[Danilo Piazzalunga (danilopiazza)]

I can still see this issue on my machine (Intel i915, reported screen size 289x21 mm), although it shows up only in GDM.
I am running an up-to-date Hardy installation.

* xdpyinfo reports:
screen #0:
  dimensions: 1280x800 pixels (289x21 millimeters)
  resolution: 112x968 dots per inch

* xrandr reports:
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 289mm x 21mm
   1280x800 60.1*+ 60.0
   1280x768 60.0
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TV disconnected (normal left inverted right x axis y axis)

* xorg.conf, with neither comments nor various InputDevice sections:
Section "Device"
 Identifier "Configured Video Device"
EndSection

Section "Monitor"
 Identifier "Configured Monitor"
EndSection

Section "Screen"
 Identifier "Default Screen"
 Monitor "Configured Monitor"
 Device "Configured Video Device"
EndSection

Section "ServerLayout"
 Identifier "Default Layout"
 Screen "Default Screen"
 InputDevice "Synaptics Touchpad"
EndSection

[Danilo Piazzalunga (danilopiazza)]

 I can reproduce it when booting from a Hardy live CD, too (which is not surprising).
/etc/X11/xorg.conf is the same (except few differences in the InputDevice sections). The (attached) Xorg.0.log is quite the same, too.

[unggnu (unggnu)]

Opening again since it still seems to be an issue in current Hardy (Bug 147081) at least with a Compaq nx7400.

[Bryce Harrington (bryce)]

I see this is also filed against -ati but the upstream bugs indicate it's fixed - is anyone with ATI hardware still experiencing this problem on 8.04.1? If so, please also check if it's still a problem with Intrepid.

[Bryce Harrington (bryce)]

Closing Gutsy tasks since we won't be SRUing to it.

[Brian Murray (brian-murray)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. In the development cycle for Intrepid there have been some vast improvements in the open source ati video driver and we could use your help testing them. Could you please download the latest Alpha CD image of Intrepid and test this particular bug just using the Live CD? You can find the latest image at http://www.ubuntu.com/testing . Your testing can help make Ubuntu and the open source ati driver even better! Thanks in advance.

[Samuel Lidén Borell (samuellb)]

I still have the same problem with Intrepid (my screen says it's 2.1 cm tall instead of 21 cm)

[Danilo Piazzalunga (danilopiazza)]

I cannot see this problem anymore with Intrepid Alpha 4, on a system with Intel i915 (-intel driver). I believe that this bug, with respect to the -intel driver, has been fixed.

* xdpyinfo reports:
screen #0:
  dimensions: 1280x800 pixels (330x210 millimeters)
  resolution: 99x97 dots per inch

* xrandr reports:
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 330mm x 210mm
   1280x800 60.1*+
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TV disconnected (normal left inverted right x axis y axis)

[puccha (yuri-schaeffer)]

Problem remains with Intrepid Alpha 4.

$ xdpyinfo
...
screen #0:
  dimensions: 1280x800 pixels (289x21 millimeters)
  resolution: 112x968 dots per inch
...

xorg.0.log attached.

furthermore I was unable to use the stand-alone installer due to huge (say about 10 times normal size) windows. Booting the live envirioment did not have this problem.

[Bryce Harrington (bryce)]

For those still having this problem, please file a NEW BUG against xorg-server on it. Include both your /var/log/Xorg.0.log, and the output of `sudo get-edid | parse-edid` (you'll need to install the read-edid package for this).

The problem here is that there is a _hardware_ bug in the monitor - it lies about its capabilities. So each case has to be handled on a case-by-case basis by 'quirking' the xserver to enable the appropriate workaround for that specific piece of hardware.

Since we have to handle each individual problem on a case-by-case basis, it is much easier to do this with separate bug reports, rather than this big one (which is getting hard to follow and keep track of who all is still having problems, and no doubt spamming people for whom the problem is long since solved. *grin*)

@Samuel, I was able to get the necessary info to compose a quirk from your Xorg.0.log, so no need for you to file a new bug.

@puccha, unfortunately your Xorg.0.log did not have detailed EDID info listed so I don't know which quirk to use for you. Please file a NEW bug and attach the info I mentioned above.

[franganghi (joered)]

A good workaround:
nx7400 - text in login input line is far too big:
Edit gdm.conf file and add the -dpi 96

[server-Standard]
name=Standard server
-command=/usr/bin/X -br -audit 0 -dpi 96

rif. http://gp3d.blogspot.com/2008/08/acer-extensa-5220-and-hp-nx7400-ubuntu.html

That was the final solution for me.
In my personal opinion, this bug can't be solved by the ubuntu team beacause it is caused by a wrong valued on the specified system: an exception must be created but an exception is non a solution... it is just a permanent workaround!

[Bryce Harrington (bryce)]

[This is an automatic notice.]

We'd like to forward your bug upstream, however upstream requires
that you first test it against their newer driver code.

To save you the effort of building the driver from source, we've built
packages for the driver and its new dependencies.

So you have a couple options:

 1. Download and test .debs for intrepid, from:
     https://edge.launchpad.net/~intel-gfx-testing/+archive

 -or-

 2. Download and test the Jaunty alpha-2 (or newer) Live CD,
     (which includes a beta of the new xserver 1.6 as well).
     See http://cdimage.ubuntu.com/releases/9.04/ for ISOs

Thanks ahead of time! You can simply reply to this email to report your
findings.

P.S., if you wish to forward your bug upstream yourself, please follow
these directions to do so:
  http://intellinuxgraphics.org/how_to_report_bug.html

[Danilo Piazzalunga (danilopiazza)]

I have tested with 8.10 (the official release, not the testing debs) and with Jaunty alpha-3 Live CD. The display size appears to be correctly detected.

[Bryce Harrington (bryce)]

Thanks for testing; it sounds like the issue is no longer being seen so I'm closing the bug.

I have also written a page for troubleshooting these kinds of dpi issues, in case others notice these problems in the future: https://wiki.ubuntu.com/X/Troubleshooting/HugeFonts

If anyone sees a wacky font size issue, please follow the troubleshooting guide and file a NEW bug; don't reopen this one.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Alois, can you please add Option "ModeDebug" "true" to your xorg.conf and attach the new log? Apparently there are several panels from Philips with product ID = 0 and not all of them need this quirk. I am wondering if there is some more identification we can use.

[Info-aloisnespor (info-aloisnespor)]

(In reply to comment #43)
> Alois, can you please add Option "ModeDebug" "true" to your xorg.conf and
> attach the new log? Apparently there are several panels from Philips with
> product ID = 0 and not all of them need this quirk. I am wondering if there is
> some more identification we can use.
>

yes, but now using xorg-server 1.6 and xf86-video-intel 2.6.99.902

will have any influence?

[Info-aloisnespor (info-aloisnespor)]

Created an attachment (id=24444)
ModeDebug On

[Sergio Zanchetta (primes2h)]

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
Gutsy task.

[Orion-cora (orion-cora)]

Reopening as there seems to be other models affected. I'll attach the Xorg.0.log with ModeDebug on for my system as well.

[Orion-cora (orion-cora)]

Created an attachment (id=25646)
Xorg log

xorg-x11-drv-ati-6.12.2-11.fc11.x86_64

HP Pavilion zv6000

[Andrew Somerville (andy16666)]

I haven't noticed anyone report this bug on an NVidia card. I have an NVidia GeForce 8800GT and I have huge text in the login manager. I also have huge text in KDE, although GNOME is fine. I'm using the NVidia proprietary driver version 180.44, and the monitor attached is a 26" Samsung TV on a DVI-HDMI link. nvidia-settings is reporting: 1360x768 pixels (161x90 millimeters) and a resolution of 215x217 dots per inch.

[Andrew Somerville (andy16666)]

I'm using Ubuntu 9.04.

[Eric Anholt (eric-anholt)]

This bug report is way too big. The original bug should be fixed, and the reporter no longer has the hardware. If people have bugs with other monitors, please open your own bugs so you actually get some attention!