Summary: | [intel] need to detect native resolution of laptop displays better | ||
---|---|---|---|
Product: | xorg | Reporter: | Bruno <bonbons> |
Component: | Driver/intel | Assignee: | Bruno <bonbons> |
Status: | RESOLVED NOTOURBUG | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | medium | CC: | michael.fu |
Version: | unspecified | Keywords: | NEEDINFO |
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 13027, 13493, 13844 | ||
Attachments: |
Description
Bruno
2007-09-16 03:09:59 UTC
Created attachment 11586 [details]
Xorg.0.log when running xorg-server-1.3 with i810-2.1.0 driver
Lines around 600 seem most intresting:
(II) intel(0): Found panel mode in BIOS VBT tables:
(II) intel(0): Modeline "1400x1050"x0.0 108.00 1400 1416 1528 1688 1050 1051 1054 1066 (64.0 kHz)
(WW) intel(0): BIOS panel mode data doesn't match probed data, continuing with probed.
(II) intel(0): BIOS mode:
(II) intel(0): Modeline "1400x1050"x0.0 108.00 1400 1416 1528 1688 1050 1051 1054 1066 (64.0 kHz)
(II) intel(0): probed mode:
(II) intel(0): Modeline "1280x1024"x0.0 107.89 1280 1356 1468 1688 1024 1038 1041 1066 (63.9 kHz)
Some 1400x1050 mode lines seem to be detected somewhere in the BIOS data, though they are not defined for use by VESA driver (at least not visible to 1.7.4 i810 driver) but driver seems to have probed different information.
In the log I can't recognize the data collected from EDID for the LVDS panel.
On a different machine, i855 based Acer TM660 with 1400x1050 15" display, there is a HEX dump of EDID data with no equivalent apearing here.
Trying to add the 1400x1050 modline listed using xrandr fails (--newmode works, --addmode LVDS <name> fails)
localhost ~ # xrandr --newmode native 108.00 1400 1416 1528 1688 1050 1051 1054 1066
localhost ~ # xrandr --addmode LVDS native
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 154 (RANDR)
Minor opcode of failed request: 18 ()
Serial number of failed request: 17
Current serial number in output stream: 18
localhost ~ # xrandr -q
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1280 x 1280
VGA disconnected (normal left inverted right)
LVDS connected 1280x1024+0+0 (normal left inverted right) 0mm x 0mm
1280x1024 60.0*+ 85.0 75.0 60.0
1280x960 85.0 60.0
1152x864 75.0
1152x768 54.8
1024x768 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 disconnected (normal left inverted right)
TV disconnected (normal left inverted right)
native (0x7f) 108.0MHz
h: width 1400 start 1416 end 1528 total 1688 skew 0 clock 64.0KHz
v: height 1050 start 1051 end 1054 total 1066 clock 60.0Hz
This is another case where us using the current programmed text mode as the native resolution fails (it works frequently, just not frequently enough). Before we switch back to using bios-probed modes, we need to make sure we have sanity checking, or fixed probing on the 855-class stuff, so that we can actually trust what we get out of the bios to display correctly. To prevent misunderstandings/mixup of results on my 2 laptops, here is a summary: Acer TM660, i855, 2.1.0 i810 driver (not tested 2.1.1): - works correctly with 2.1.0 i810 driver - I have not seen crashes yet - detects and uses 1400x1050 resolution, console is 1280x1024 Fujitsu-Siemens S7020, i915, 2.1.0 and 2.1.1 driver - fails to properly detect and use 1400x1050 resolution - often (not always) crashed when switching to console (when it does not crash it takes a long time to unscramble the console) (when X crashes it seems to end up in a uninterruptible loop (in kernel/interrupt?) - CPU FAN starts running full-speed) - falls back to 1280x1024 resolution, aligned top-left (black border only right and bottom) Both LVDS panels have 1400x1050 resolution, linux console is centered (black border on each side) In both cases I'm using the intel frambuffer driver for linux console, 2.6.22.* kernel The acer probably has connected DDC on the panel while the fujitsu doesn't, which would explain one using the console 1280x1024 mode and the other using native. Note that bad behavior is generally expected with intelfb, and removing that would be required before debugging any VT switch issues. Bruno, Jesse Barnes has fixed several VT switch related bugs. I suggest you to re-test to see if the vt-switch issue is gone or not. Again, please follow Eric's suggestion to remove intelfb framebuffer driver. We will focus on the display mode issue in this bug. If the VT-switch still doesn't work for you, would you please open another bug? thanks! Regarding VT switch: I will do some more testing without intelfb. For now, with 2.2.0 driver VT switches work in an acceptable manner. Artefacts show up only when code has to be loaded from disk (e.g. only on the first of two consecutive switches). Regarding mode detection: For the ACER the driver dumps DDC data in the log. For the Fujitsu either it can't get it or there is no DDC data (any way to check for sure?) - don't know if/how Windows gets the information it needs to limit available modes. As stated before, mode detection on Acer is fine, the Fujitsu detects data in BIOS structures but prefers the programmed mode (disabling this preference I get 1400x1050, see my patch) Below list of modes detected by Xorg when running with my patch and configured to not prefer current mode to the one it finds in BIOS structures (II) intel(0): Modeline "1400x1050"x60.0 108.00 1400 1416 1528 1688 1050 1051 1054 1066 (64.0 kHz) (II) intel(0): Modeline "1400x1050"x74.8 155.80 1400 1464 1784 1912 1050 1052 1064 1090 +hsync +vsync (81.5 kHz) (II) intel(0): Modeline "1400x1050"x60.0 122.00 1400 1488 1640 1880 1050 1052 1064 1082 +hsync +vsync (64.9 kHz) (II) intel(0): Modeline "1280x1024"x85.0 157.50 1280 1344 1504 1728 1024 1025 1028 1072 +hsync +vsync (91.1 kHz) (II) intel(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) intel(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline "1280x960"x85.0 148.50 1280 1344 1504 1728 960 961 964 1011 +hsync +vsync (85.9 kHz) (II) intel(0): Modeline "1280x960"x60.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) intel(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) intel(0): Modeline "1152x768"x54.8 65.00 1152 1178 1314 1472 768 771 777 806 +hsync +vsync (44.2 kHz) (II) intel(0): Modeline "1024x768"x85.0 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (68.7 kHz) (II) intel(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) intel(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) intel(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) intel(0): Modeline "800x600"x85.1 56.30 800 832 896 1048 600 601 604 631 +hsync +vsync (53.7 kHz) (II) intel(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) intel(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) intel(0): Modeline "640x480"x85.0 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (43.3 kHz) (II) intel(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) intel(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) intel(0): Modeline "720x400"x85.0 35.50 720 756 828 936 400 401 404 446 -hsync +vsync (37.9 kHz) (II) intel(0): Modeline "640x400"x85.1 31.50 640 672 736 832 400 401 404 445 -hsync +vsync (37.9 kHz) (II) intel(0): Modeline "640x350"x85.1 31.50 640 672 736 832 350 382 385 445 +hsync -vsync (37.9 kHz) Mode switching works fine while Xorg is running. Created attachment 13400 [details] [review] Patch to add option to not force use of programmed mode when missing DDC Patch to 2.2.0 that adds configuration option "NoProgrammed" that, when set to "true", does not force programmed mode instead of eventually detected mode in BIOS structures Makes X able to run at 1400x1050 on my Fujitsu-Siemens in term of root-cause, this bug is a dup of bug# 11917 Bruno, Just want to make sure the display mode issue still exist _without_ intelfb loaded. Is the log in comment# 2 also got when intelfb is loaded? If yes, would you please post a new one _without_ intelfb loaded ( without the patch in comment# 7, too)? thanks. Created attachment 13884 [details]
Xorg log with vanilla video-intel-2.2.0 - kernel using vesafb
** Fujitsu-Siemens S7020 **
Yes, I do have the same mode issues with only vesafb on kernel side.
X starts in 1280x1024 mode (aligned on top-left corner).
Running Gentoo xorg-server-1.4-r2, xf86-video-intel-2.2.0 (vanilla)
The crash when exiting X seems to belong to xorg-server (see end of log), just switching to linux console is mostly fine.
Bruno, would you please get rid of any frame buffer driver from kernel and give us an update about the bug then? thanks.. Created attachment 14039 [details] Log booting in text mode from kernel without framebuffer support (In reply to comment #11) > Bruno, would you please get rid of any frame buffer driver from kernel and > give us an update about the bug then? thanks.. Booting with kernel without framebuffer support (2.6.24) and vga=normal X ends up in 1400x1050 resolution with the attached log. Looks like text modes are visible to X as if they were programmed to panel size... Booting the kernel with vga=0x31A (no framebuffer support -> blind console) X ends up in the same state as if booting with vesafb, taking the 1280x1024 graphical mode. ok. thanks, Bruno. This is known issue then. I'll mark this as NOTOURBUG. |
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.