Bug description: Incorrect display dimensions are detected by the driver: # grep -C1 dimension /tmp/dpyinfo-huge-fonts.txt screen #0: dimensions: 1280x800 pixels (289x21 millimeters) resolution: 112x968 dots per inch which differ from those reported by EDID: # monitor-get-edid|monitor-parse-edid EISA ID: LPL2a00 Screen size: 33.0 cm x 21.0 cm (15.40 inches, aspect ratio 16/10 or 15/9 = 1.57) Gamma: 2.2 Digital signal # Monitor preferred modeline (60.1 Hz vsync, 49.5 kHz hsync, ratio 16/10, 98 dpi) ModeLine "1280x800" 71.25 1280 1328 1360 1440 800 802 808 823 -hsync -vsync The incorrect dimensions result in bogus resolution (by the look of it, the 968 dpi from above), and huge (unusable) fonts. Forcing the correct dimensions by the DisplaySize option had no effect: Section "Monitor" Identifier "monitor1" VendorName "Generic" ModelName "Flat Panel 1280x800" HorizSync 29.5-90 VertRefresh 60 DisplaySize 330 210 as did disabling DDC: Option "DDC" "off" The machine is currently usable (my wife is using it as her sole machine, opportunities for troubleshooting are limited, which is why it took over a week to report this) by forcing the resolution via the X -dpi option: # grep dpi /usr/share/config/kdm/kdmrc ServerArgsLocal=-deferglyphs 16 -nolisten tcp -dpi 96 System environment: -- chipset: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) -- system architecture: XX-bit 32-bit # uname -a Linux blackshark 2.6.31.2-desktop-0.rc1.1mnb #1 SMP Sat Oct 3 19:53:59 EDT 2009 i686 Genuine Intel(R) CPU T2050 @ 1.60GHz GNU/Linux -- xf86-video-intel: # rpm -q x11-driver-video-intel x11-driver-video-intel-2.9.0-1mdv2010.0 -- xserver: # rpm -q x11-server-xorg x11-server-xorg-1.6.4-2mdv2010.0 -- mesa: # rpm -qa '*mesa*' libmesaglu1-7.5-2mdv2010.0 libmesaglut3-7.5-2mdv2010.0 libmesagl1-7.5-2mdv2010.0 -- libdrm: # rpm -qa '*libdrm*' libdrm_intel1-2.4.13-1mdv2010.0 libdrm2-2.4.13-1mdv2010.0 libdrm-common-2.4.13-1mdv2010.0 -- kernel: # uname -r 2.6.31.2-desktop-0.rc1.1mnb -- Linux distribution: Mandriva Linux 2010.0-rc1 with relevant updates (x11-driver-video-intel, x11-server-xorg,kernel to cooker or pre-rc2) -- Machine or mobo model: HP Pavillion DV5236EA -- Display connector: Built-in LCD panel. Reproducing steps: Boot Mandriva 2010.0 rc1 (rc2 is probably affected) live image, when X starts and welcome screen appears, only a few words are visible due to the huge fonts. After the welcome screen, for some reason the fonts are smaller (maybe krandr gets it right?). However, after an install, the font sizes in the installed X are huge again (e.g. system-settings only shows 3 items of the toolbar in the window taking up the whole screen) Additional info: I think KMS is enabled by default, plymouth is being used for splash screen, I have not tested without either as it didn't seem relevant.
On Mon, Oct 12, 2009 at 13:20:47 -0700, bugzilla-daemon@freedesktop.org wrote: > Incorrect display dimensions are detected by the driver: > # grep -C1 dimension /tmp/dpyinfo-huge-fonts.txt > screen #0: > dimensions: 1280x800 pixels (289x21 millimeters) > resolution: 112x968 dots per inch > we need an X log, please. See http://intellinuxgraphics.org/how_to_report_bug.html
Created attachment 30361 [details] Xorg log when started without -dpi option Interesting lines in the log file: (**) intel(0): Display dimensions: (330, 210) mm (**) intel(0): DPI set to (98, 96) [...] (II) GLX: Initialized DRI2 GL provider for screen 0 (II) intel(0): Setting screen physical size to 289 x 21 xrandr --verbose in this X session then reports: LVDS1 connected 1280x800+0+0 (0x3e) normal (normal left inverted right x axis y axis) 289mm x 21mm
Created attachment 30362 [details] output of xrandr --verbose during affected session
Created attachment 30363 [details] Screenshot (scaled to 25%) during affected session
Created attachment 30364 [details] xorg.conf
Will you please try the latest linux upstream kernel and attach the output of dmesg, Xorg.0,log, xrandr, xdpyinfo? Please add the boot option of "drm.debug=0x06" and boot the system with KMS enabled. thanks.
Created attachment 30467 [details] dmesg from kernel 2.6.31.4 Latest stable kernel, or latest -rc kernel? The one I could use this morning before work was Mandriva cooker's kernel-linus-2.6.31.4-1mdv (see http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel-linus/current/ for details). drm.debug=0x06 seems to not be a valid option according to dmesg, or do I need other kernel options enabled at build-time? Config used is I think this one: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel-linus/current/SOURCES/i386_defconfig?revision=454215&view=markup More logs to follow.
Created attachment 30468 [details] Xorg.log.0 when booted on kernel-linus 2.6.31.4-1mdv without any dpi option
Created attachment 30469 [details] xrandr --verbose output on kernel-linus 2.6.31.4-1mdv against X with no -dpi option xrandr output was: Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 289mm x 21mm 1280x800 60.1*+ 1024x768 60.0 800x600 60.3 640x480 59.9 TV1 disconnected (normal left inverted right x axis y axis)
Created attachment 30470 [details] xdpyinfo output on kernel-linus 2.6.31.4-1mdv against X with no -dpi option For reference, /proc/cmdline was: BOOT_IMAGE=2.6.31.4-1 root=/dev/VGsys/stable resume=/dev/VGsys/swap splash=silent vga=788 drm.debug=0x06 $ zcat /proc/config.gz |grep KMS CONFIG_DRM_I915_KMS=y # CONFIG_DRM_RADEON_KMS is not set $ /sbin/lsmod|grep i915 i915 233512 2 drm 172768 2 i915 i2c_algo_bit 6248 1 i915 i2c_core 30680 4 i2c_i801,i915,drm,i2c_algo_bit video 20604 1 i915 $ /sbin/modinfo i915 filename: /lib/modules/2.6.31.4-1mdv/kernel/drivers/gpu/drm/i915/i915.ko.gz license: GPL and additional rights description: Intel Graphics author: Tungsten Graphics, Inc. license: GPL and additional rights srcversion: D1511EA127CA6D57AF08FD1 alias: pci:v00008086d00000046sv*sd*bc03sc00i* alias: pci:v00008086d00000042sv*sd*bc03sc00i* alias: pci:v00008086d000035E8sv*sd*bc03sc00i* alias: pci:v00008086d0000A011sv*sd*bc03sc00i* alias: pci:v00008086d0000A001sv*sd*bc03sc00i* alias: pci:v00008086d00002E32sv*sd*bc03sc00i* alias: pci:v00008086d00002E22sv*sd*bc03sc00i* alias: pci:v00008086d00002E12sv*sd*bc03sc00i* alias: pci:v00008086d00002E02sv*sd*bc03sc00i* alias: pci:v00008086d00002A42sv*sd*bc03sc00i* alias: pci:v00008086d00002A12sv*sd*bc03sc00i* alias: pci:v00008086d00002A02sv*sd*bc03sc00i* alias: pci:v00008086d000029D2sv*sd*bc03sc00i* alias: pci:v00008086d000029C2sv*sd*bc03sc00i* alias: pci:v00008086d000029B2sv*sd*bc03sc00i* alias: pci:v00008086d000029A2sv*sd*bc03sc00i* alias: pci:v00008086d00002992sv*sd*bc03sc00i* alias: pci:v00008086d00002982sv*sd*bc03sc00i* alias: pci:v00008086d00002972sv*sd*bc03sc00i* alias: pci:v00008086d000027AEsv*sd*bc03sc00i* alias: pci:v00008086d000027A2sv*sd*bc03sc00i* alias: pci:v00008086d00002772sv*sd*bc03sc00i* alias: pci:v00008086d00002592sv*sd*bc03sc00i* alias: pci:v00008086d0000258Asv*sd*bc03sc00i* alias: pci:v00008086d00002582sv*sd*bc03sc00i* alias: pci:v00008086d00002572sv*sd*bc03sc00i* alias: pci:v00008086d00003582sv*sd*bc03sc00i* alias: pci:v00008086d00002562sv*sd*bc03sc00i* alias: pci:v00008086d00003577sv*sd*bc03sc00i* depends: drm,i2c-core,video,i2c-algo-bit vermagic: 2.6.31.4-1mdv SMP mod_unload modversions 586 parm: modeset:int parm: fbpercrtc:int No relevant module options are set in /etc/modprobe.conf or similar.
Created attachment 30471 [details] [review] update the height/width again after getting the mode Will you please try the debug patch and see whether the issue still exists? Thanks.
The patch seems to have fixed the issue: $ ps auxww|grep -E [X] root 3329 6.6 3.6 26756 18472 tty7 Ss+ 22:27 0:10 /etc/X11/X -deferglyphs 16 -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-2UI5fH $ xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 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 TV1 disconnected (normal left inverted right x axis y axis) $ xdpyinfo |grep -A1 dim dimensions: 1280x800 pixels (330x210 millimeters) resolution: 99x97 dots per inch I have logged a bug downstream (https://qa.mandriva.com/show_bug.cgi?id=54712) to get this on the radar for Mandriva 2010.0 release which is imminent.
Thanks for the test. In the test patch the rotation case is not considered. Will you please try to test it again after I re-write the patch? Thanks.
(In reply to comment #13) > Will you please try to test it again after I re-write the patch? I'm sure Buchan will indeed re-test. I don't mean to rush you but is there an ETA on a final patch? We're currently in final freeze and it would be great to get a version we can ship... that said I'd really need to get it into a package today or tomorrow at the latest. If it's not likely to happen, that fine, we can always ship it as an update, but it's obviously nicer if we can fix stuff to work OOTB as much as possible :) Alternatively, what danger comes from shipping the current patch? xrandr rotation will break? If so, that's probably still better than just now.... Many thanks for your work.
I had the same issue until I applied the above patch. I can test a new patch in case Buchan Milne can't.
Created attachment 31107 [details] [review] Move the EDID quirk into the correct place Will you please try the updated patch on the xserver and see whether the issue still exists? Thanks.
Weird. The quirk will only trigger (at least it will only write about it in /var/log/Xorg.0.log) when I use the patch to the Intel drivers posted above. When I don't it won't trigger and the fonts are still huge. I use (and apply the patches to) xserver-xorg-video-intel-2.9.0 and xorg-server-1.6.4
(In reply to comment #17) > Weird. The quirk will only trigger (at least it will only write about it in > /var/log/Xorg.0.log) when I use the patch to the Intel drivers posted above. > When I don't it won't trigger and the fonts are still huge. I use (and apply > the patches to) xserver-xorg-video-intel-2.9.0 and xorg-server-1.6.4 > Have you tried the patch on the xorg-server? If so, please attach the xorg log. thanks
Created attachment 31131 [details] Xorg.log.intelpatch Xorg with your patch, the Intel driver also patched
Created attachment 31132 [details] Xorg.log.nointelpatch Only X.org patched. As you can see the quirk isn't triggered
Just in case my English wasn't clear enough (I'm not a native speaker): I applied you patch to x.org in both cases. The difference is that in one case I also applied you patch for the Intel driver to the Intel driver. Only then I got normal size fonts. Only then "(II) intel(0): EDID quirk: Detailed timings give vertical size in cm." appeared in the Xorg.log. (I also got normal size fonts with the patch to the Intel drivers alone as reported earlier)
(In reply to comment #21) > Just in case my English wasn't clear enough (I'm not a native speaker): I > applied you patch to x.org in both cases. The difference is that in one case I > also applied you patch for the Intel driver to the Intel driver. Only then I > got normal size fonts. Only then "(II) intel(0): EDID quirk: Detailed > timings give vertical size in cm." appeared in the Xorg.log. (I also got normal > size fonts with the patch to the Intel drivers alone as reported earlier) > Thanks for the test and confirmation. After I look at the source code of Xorg, it seems that the patch in comment #16 can work on the latest xorg tree. But it can't work on the xorg-1.6.4 if the system is booted with KMS enabled. Of course it can work if the system is booted with KMS enabled. thanks.
The following commit is already shipped in the latest Xserver tree. And this issue can be fixed by the following commit: commit 19f7c15e2008dab3c46ba3e14dfa353d01c74f72 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Fri Nov 20 14:43:35 2009 +0800 xfree86: Edid quirk for Philips LCD LP154W01 So this bug will be marked as resolved. Thanks.
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.