Bug 12440

Summary: [intel] need to detect native resolution of laptop displays better
Product: xorg Reporter: Bruno <bonbons>
Component: Driver/intelAssignee: Bruno <bonbons>
Status: RESOLVED NOTOURBUG QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: michael.fu
Version: unspecifiedKeywords: NEEDINFO
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 13027, 13493, 13844    
Attachments:
Description Flags
Xorg.0.log when running xorg-server-1.3 with i810-2.1.0 driver
none
Patch to add option to not force use of programmed mode when missing DDC
none
Xorg log with vanilla video-intel-2.2.0 - kernel using vesafb
none
Log booting in text mode from kernel without framebuffer support none

Description Bruno 2007-09-16 03:09:59 UTC
On my Fujitsu-Siemens laptop (S7020 series) with 1400x1050 14" display and i915 chipset/graphics X limits resolution to 1280x1024 as used by linux console.

With 1.7.4 driver in combination with 855resolution or 915resolution it was possible to use native resolution, with drivers 2.1.0 and 2.1.1 maximum that xorg accepts to set is 1280x1024.
On >= 2.1.0 switching back to linux console often ends in X segfaults (same when exiting xorg with CTRL+ALT+BACKSPACE or sending SIGTERM to X server)

xorg-server versions used: 
 1.2.0 with 1.7.4 i810 driver
 1.3.0.0 with 2.1.0 i810 driver
 1.4 with 2.1.1 i810 driver

I'm using Gentoo, installing xorg and drivers from portage. I did recompile all drivers (video and input) for each xorg-server version to make sure the segfaults not being causes by version mismatch between xorg-server drivers were compiled against
Comment 1 Bruno 2007-09-16 03:20:11 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
Comment 2 Eric Anholt 2007-09-17 12:22:50 UTC
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.
Comment 3 Bruno 2007-09-17 12:49:23 UTC
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
Comment 4 Eric Anholt 2007-10-18 17:34:05 UTC
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.
Comment 5 Michael Fu 2007-12-27 18:56:34 UTC
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!
Comment 6 Bruno 2007-12-28 13:58:04 UTC
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.
Comment 7 Bruno 2007-12-28 14:02:32 UTC
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
Comment 8 Michael Fu 2008-01-07 00:37:41 UTC
in term of root-cause, this bug is a dup of bug# 11917
Comment 9 Michael Fu 2008-01-22 19:33:27 UTC
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.
Comment 10 Bruno 2008-01-23 10:26:09 UTC
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.
Comment 11 Michael Fu 2008-01-28 19:20:41 UTC
Bruno, would you please get rid of any frame buffer driver from kernel and give us an update about the bug then? thanks..
Comment 12 Bruno 2008-01-30 10:39:28 UTC
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.
Comment 13 Michael Fu 2008-02-14 01:21:11 UTC
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.