| Summary: | [snb regression] ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Toralf Förster <toralf.foerster> | ||||||||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | medium | ||||||||||||||
| Version: | XOrg git | ||||||||||||||
| Hardware: | Other | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 75964 [details]
dmesg (bad) kernel 3.8.2
Created attachment 75966 [details] dmesg (much more bad) kernel 3.8.2 This dmesg shows a boot phase where the kernel runs into this issue too : https://bugzilla.kernel.org/show_bug.cgi?id=48791 /me wonders wehther there's something interesting for that bug report too in this dmesg ? Xorg.log would be most interesting here. Created attachment 75971 [details]
X.org log 3.7.10
Created attachment 75972 [details]
X.org log 3.8.2
This is the key difference: 3.7.10: [ 34.036] (II) intel(0): Using exact sizes for initial modes [ 34.036] (II) intel(0): Output LVDS1 using initial mode 1600x900 [ 34.036] (II) intel(0): Output VGA1 using initial mode 1600x900 3.8.2: [ 31.303] (II) intel(0): Using fuzzy aspect match for initial modes [ 31.303] (II) intel(0): Output LVDS1 using initial mode 1024x768 [ 31.303] (II) intel(0): Output VGA1 using initial mode 1024x768 as we no longer add a 16x9 mode for VGA1. The other wtf: [ 20.701041] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on I'm wondering if for a closed LID the resolution should be set to the one of the external dispaly rather than to the resolution of the internal display ? (OTOH I do have for KDE a script solution in $HOME/.kde4/env/ which works fine) (In reply to comment #8) > I'm wondering if for a closed LID the resolution should be set to the one of > the external dispaly rather than to the resolution of the internal display ? > (OTOH I do have for KDE a script solution in $HOME/.kde4/env/ which works > fine) The problem is we have a history of manufacturers get lid state horribly wrong, so much so that we cannot trust it by default. Use i915.i915_panel_ignore_lid=0 at your peril. Hi, I have a similar problem in my Lenovo T400 (Core 2 Duo, GMA4500HD). Just upgraded from 3.7.2 to 3.8.3 and the laptop LCD monitor resolution is incorrect after booting up. Here is an except from Xorg.log: [ 42.245] (II) intel(0): Printing probed modes for output LVDS1 [ 42.245] (II) intel(0): Modeline "1280x800"x60.0 82.06 1280 1332 1396 1672 800 803 806 818 -hsync -vsync (49.1 kHz eP) [ 42.245] (II) intel(0): Modeline "1280x800"x49.0 57.05 1280 1332 1396 1397 800 803 806 834 -hsync -vsync (40.8 kHz e) [ 42.245] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz d) [ 42.245] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz d) [ 42.245] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz d) [ 42.245] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz d) [ 42.261] (II) intel(0): EDID for output VGA1 [ 42.261] (II) intel(0): Printing probed modes for output VGA1 [ 42.261] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 42.261] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 42.261] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 42.261] (II) intel(0): Modeline "848x480"x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [ 42.261] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 489 492 525 -hsync -vsync (31.5 kHz e) [ 42.261] (II) intel(0): EDID for output HDMI1 [ 42.261] (II) intel(0): EDID for output DP1 [ 42.261] (II) intel(0): EDID for output HDMI2 [ 42.261] (II) intel(0): EDID for output DP2 [ 42.261] (II) intel(0): EDID for output DP3 [ 42.261] (II) intel(0): Output LVDS1 connected [ 42.261] (II) intel(0): Output VGA1 connected [ 42.261] (II) intel(0): Output HDMI1 disconnected [ 42.261] (II) intel(0): Output DP1 disconnected [ 42.261] (II) intel(0): Output HDMI2 disconnected [ 42.261] (II) intel(0): Output DP2 disconnected [ 42.261] (II) intel(0): Output DP3 disconnected [ 42.261] (II) intel(0): Using fuzzy aspect match for initial modes [ 42.261] (II) intel(0): Output LVDS1 using initial mode 1024x768 [ 42.261] (II) intel(0): Output VGA1 using initial mode 1024x768 [ 42.261] (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [ 42.261] (II) intel(0): Kernel page flipping support detected, enabling [ 42.261] (**) intel(0): Display dimensions: (300, 190) mm [ 42.261] (**) intel(0): DPI set to (86, 102) Please let me know if you need more details. Regards, Pedro Sorry just to add a comment to the above: this is in my main laptop LCD, without any external monitor attached. (In reply to comment #11) > Sorry just to add a comment to the above: this is in my main laptop LCD, > without any external monitor attached. You have a completely separate issue, a regression in 3.8.3 that affects gm45. I think the answer here is for xf86InitialConfiguration() to create the compatible GTF mode on the fly. Yeah, I think this one here is wontfix since we've intentionally stopped adding tons of modes - they've actually been added wrongly in some cases: commit 740922ee575f8ee4daa2bfd3db5f69dd7573fc76 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 15 13:36:27 2013 -0200 drm: don't add inferred modes for monitors that don't support them commit 196e077dc165a307efbd9e7569f81bbdbcf18f65 upstream. If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, "the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks". For more information, please see the EDID spec, check the notes of the table that explains the "Feature Support" byte (18h) and also the notes on the tables of the section that explains "Display Range Limits & Additional Timing Description Definition (tag #FDh)". Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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.
Created attachment 75963 [details] dmesg (good) kernel 3.7.10 It is a (small) regression to 3.7.10 with intel integrated graphics i915 - but nevertheless : With an external VGA display (1680x1050) and a closed internal LVDS1 display (1440x900) the external display starts X11 with 1440x900 - for kernel 3.7.x. With 3.8.2 (and .1) now the external display is driven with just 800x600.