[i945G] [intel KMS regression] wrong X resolution (fuzzy aspect match)

Bug #392544 reported by Oibaf
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
High
linux (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: xorg

I am testing current karmic LiveCD. When booting without KMS X gets the correct 1280x1024 resolution of my monitor (a "I-See S 171" 17 inches). This is what I see with my monitor's OSD:

while booting with usplash: 640x480@59,9Hz
X: 1280x1024@59,9Hz
when switching to a VT: 720x400@70Hz
while shutting down with usplash: 640x480@59,9Hz

When booting with KMS (adding i915.modeset=1 to kernel command line) VT and usplash while shutting down have a 1280x1024 resolution, but X has a lower 1024x768 resolution. This is what I see with my monitor's OSD:

while booting with usplash: 1280x1024@74,6Hz with 2.6.31-2.16 [was 640x480@59,9Hz with 2.6.30-9.10 kernel]
X: 1024x768@75,1Hz
when switching to a VT: 1280x1024@74,6Hz
while shutting down with usplash: 1280x1024@74,6Hz

linux-image-2.6.30-9-generic - 2.6.30-9.10
xserver-xorg-video-intel - 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2
xserver-xorg-core - 2:1.6.1.901-2ubuntu1

ProblemType: Bug
Architecture: i386
Date: Fri Jun 26 13:32:36 2009
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Alpha i386 (20090623)
Package: xorg 1:7.4~5ubuntu21
ProcEnviron:
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.30-9.10-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4~5ubuntu21
 libgl1-mesa-glx 7.4.1-1ubuntu2
 libdrm2 2.4.11-0ubuntu1
 xserver-xorg-video-intel 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2
 xserver-xorg-video-ati 1:6.12.2-2ubuntu2
SourcePackage: xorg
Uname: Linux 2.6.30-9-generic i686
system:
 distro: Ubuntu
 architecture: i686kernel: 2.6.30-9-generic

Revision history for this message
Oibaf (oibaf) wrote :
Revision history for this message
Oibaf (oibaf) wrote :

The previous attached files where taken with KMS enabled.

Bryce Harrington (bryce)
affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Geir Ove Myhr (gomyhr)
tags: added: 945g karmic kms resolution
summary: - [intel KMS regression] wrong X resolution
+ [i945G] [intel KMS regression] wrong X resolution
Revision history for this message
Geir Ove Myhr (gomyhr) wrote : Re: [i945G] [intel KMS regression] wrong X resolution

Thank you for reporting this bug. There is some additional information that may be useful for troubleshooting this.
- Could you add the line
  Option "ModeDebug" "true"
to the "Device" section of your xorg.conf and upload the Xorg.0.log generated from this for both KMS and UMS (UMS means Userland Mode Setting).
- Could you upload the output of `xrandr --verbose` for both cases?

I'm afraid the KMS part of the driver is not very good at being verbose for the moment (I'm not sure if ModeDebug makes a difference for KMS at all actually). xrandr output is also less informative with KMS. But at least it is a start.

Revision history for this message
Oibaf (oibaf) wrote :

When adding Option "ModeDebug" "true" with KMS the only differences in the log I noticed are:

-(==) Log file: "/var/log/Xorg.1.log", Time: Tue Jul 7 14:32:26 2009
+(==) Log file: "/var/log/Xorg.1.log", Time: Tue Jul 7 14:35:02 2009

+(**) intel(0): Option "ModeDebug" "true"

-(II) intel(0): 0x05000000-0x053fffff: front buffer (4096 kB) X tiled
-(II) intel(0): 0x04400000-0x04409fff: HW cursors (40 kB)
+(II) intel(0): 0x08000000-0x083fffff: front buffer (4096 kB) X tiled
+(II) intel(0): 0x07e00000-0x07e09fff: HW cursors (40 kB)

Revision history for this message
Oibaf (oibaf) wrote :

A good news is that while booting with usplash resolution is now 1280x1024@74,6Hz and not 640x480@59,9Hz (X still has 1024x768@75,1 Hz).

description: updated
Revision history for this message
Oibaf (oibaf) wrote :

With UMS the log is more verbose.

Revision history for this message
Oibaf (oibaf) wrote :
Revision history for this message
Oibaf (oibaf) wrote :

Note that I am now testing:
linux-image-2.6.31-2-generic - 2.6.31-2.16
xserver-xorg-video-intel - 2.7.99.1+git20090602.ec2fde7c-0ubuntu5

Revision history for this message
Bryce Harrington (bryce) wrote :

According to your xrandr output, 1280x1024 is available and selected. Is this issue resolved with you with those updates? Maybe we can close this bug now.

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Incomplete
Revision history for this message
Oibaf (oibaf) wrote :

> According to your xrandr output, 1280x1024 is available and selected.

This is only the case with UMS (i.e. without KMS). The attached xrandr output with KMS shows that 1024x768 is used and 1280x1024 is not available.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → New
Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=27580)
xrandr-verbose-kms.txt

Forwarding this bug from Ubuntu reporter Fabio Pedretti:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/392544

[Problem]
Booting without KMS gives a 1280x1024 resolution, but with KMS enabled X does not detect this as a valid resolution and loads with a lower resolution, 1024x768, instead.

(II) intel(0): Not using mode "1280x1024" (bad mode clock/interlace/doublescan)
(II) intel(0): Printing probed modes for output VGA1
...
(II) intel(0): Output VGA1 connected
(II) intel(0): Using fuzzy aspect match for initial modes
(II) intel(0): Output VGA1 using initial mode 1024x768
(==) intel(0): video overlay key set to 0x101fe

[Original Report]
I am testing current karmic LiveCD. When booting without KMS X gets the correct 1280x1024 resolution of my monitor (a "I-See S 171" 17 inches). This is what I see with my monitor's OSD:

while booting with usplash: 640x480@59,9Hz
X: 1280x1024@59,9Hz
when switching to a VT: 720x400@70Hz
while shutting down with usplash: 640x480@59,9Hz

When booting with KMS (adding i915.modeset=1 to kernel command line) VT and usplash while shutting down have a 1280x1024 resolution, but X has a lower 1024x768 resolution. This is what I see with my monitor's OSD:

while booting with usplash: 1280x1024@74,6Hz with 2.6.31-2.16 [was 640x480@59,9Hz with 2.6.30-9.10 kernel]
X: 1024x768@75,1Hz
when switching to a VT: 1280x1024@74,6Hz
while shutting down with usplash: 1280x1024@74,6Hz

linux-image-2.6.30-9-generic - 2.6.30-9.10
xserver-xorg-video-intel - 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2
xserver-xorg-core - 2:1.6.1.901-2ubuntu1

ProblemType: Bug
Architecture: i386
Date: Fri Jun 26 13:32:36 2009
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Alpha i386 (20090623)
Package: xorg 1:7.4~5ubuntu21
ProcEnviron:
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.30-9.10-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4~5ubuntu21
 libgl1-mesa-glx 7.4.1-1ubuntu2
 libdrm2 2.4.11-0ubuntu1
 xserver-xorg-video-intel 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2
 xserver-xorg-video-ati 1:6.12.2-2ubuntu2
SourcePackage: xorg
Uname: Linux 2.6.30-9-generic i686
system:
 distro: Ubuntu
 architecture: i686kernel: 2.6.30-9-generic

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=27581)
Xorg log with KMS and Option "ModeDebug" "true"

Revision history for this message
In , Bryce Harrington (bryce) wrote :

While booting with usplash resolution is 1280x1024@74,6Hz and not 640x480@59,9Hz (X still has 1024x768@75,1 Hz).

Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Bryce Harrington (bryce) wrote : Re: [i945G] [intel KMS regression] wrong X resolution

Fabio, I've forwarded your bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=22716 - please subscribe to this bug in case upstream needs further information or wishes you to test something. Thanks ahead of time.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Triaged
summary: - [i945G] [intel KMS regression] wrong X resolution
+ [i945G] [intel KMS regression] wrong X resolution (fuzzy aspect match)
Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Revision history for this message
In , Ling-ma (ling-ma) wrote :

please upload your xorg.conf file in KMS mode.

Thanks
Ma Ling

Revision history for this message
In , Oibaf (oibaf) wrote :

(In reply to comment #3)
> please upload your xorg.conf file in KMS mode.

I am the original reporter of the Ubuntu bug. I have an empty xorg.conf.

Revision history for this message
In , Ling-ma (ling-ma) wrote :

(In reply to comment #4)
> (In reply to comment #3)
> > please upload your xorg.conf file in KMS mode.
> I am the original reporter of the Ubuntu bug. I have an empty xorg.conf.

please run the below command and move xorg.conf into /etc/X11/ directory.
$Xorg -configure

Revision history for this message
In , Michael Fu (michael-fu-intel) wrote :

could it because the native preferred modeline is filtered out by:

"(II) intel(0): Not using mode "1280x1024" (bad mode clock/interlace/doublescan)
"

then xserver falls into fuzzy aspect match algorithm to pick the initial mode?

Before X start, KMS has choose 1280x1024..

Revision history for this message
In , Ling-ma (ling-ma) wrote :

(In reply to comment #6)
> could it because the native preferred modeline is filtered out by:
> "(II) intel(0): Not using mode "1280x1024" (bad mode
> clock/interlace/doublescan)
> "
> then xserver falls into fuzzy aspect match algorithm to pick the initial mode?
> Before X start, KMS has choose 1280x1024..

when boot start, kms control all operation, and not check mode line seriously as X does. When X start, it take over system, and discard 1280x1024. So I think we can not get 1280x1024 in UMS either.

Revision history for this message
In , Michael Fu (michael-fu-intel) wrote :

(In reply to comment #7)
> (In reply to comment #6)
> > could it because the native preferred modeline is filtered out by:
> > "(II) intel(0): Not using mode "1280x1024" (bad mode
> > clock/interlace/doublescan)
> > "
> > then xserver falls into fuzzy aspect match algorithm to pick the initial mode?
> > Before X start, KMS has choose 1280x1024..
>
> when boot start, kms control all operation, and not check mode line seriously
> as X does. When X start, it take over system, and discard 1280x1024. So I think
> we can not get 1280x1024 in UMS either.
>

but the user says "Booting without KMS gives a 1280x1024 resolution"... see the first comment.

Revision history for this message
In , Michael Fu (michael-fu-intel) wrote :

(In reply to comment #4)
> (In reply to comment #3)
> > please upload your xorg.conf file in KMS mode.
>
> I am the original reporter of the Ubuntu bug. I have an empty xorg.conf.
>

Fabio, could you please give us a xorg.log with KMS disabled, and modedebug turns on? this will help us to see how UMS works...thanks.

Revision history for this message
In , Oibaf (oibaf) wrote :

> Fabio, could you please give us a xorg.log with KMS disabled, and modedebug
> turns on? this will help us to see how UMS works...thanks.

I already attached this to the Ubuntu bug report:

Xorg.log with KMS disabled + "ModeDebug" "true":
http://launchpadlibrarian.net/28767779/Xorg.1.log

Also, output of xrandr --verbose with KMS disabled:
http://launchpadlibrarian.net/28767801/xrandr-verbose-UMS.txt

Revision history for this message
In , Ling-ma (ling-ma) wrote :

Created an attachment (id=27701)
pleaset try the patch on your machine in KMS mode, thanks.

please try the debug patch in KMS mode, then upload dmesg.
Then patch intends to print all modes from edid in KMS mode, which are transmitted to X.

Thanks
Ma Ling

Revision history for this message
In , Oibaf (oibaf) wrote :

(In reply to comment #11)
> Created an attachment (id=27701) [details]
> pleaset try the patch on your machine in KMS mode, thanks.
>
> please try the debug patch in KMS mode, then upload dmesg.
> Then patch intends to print all modes from edid in KMS mode, which are
> transmitted to X.

The patch is for the linux kernel rigth?

Currently I am doing tests with the LiveCD, I can compile the -intel driver and restart X from the LiveCD, but can't do that with the kernel.

Unless Bryce make available a LiveCD with this kernel patch... :)

Revision history for this message
In , Ling-ma (ling-ma) wrote :

(In reply to comment #12)
> (In reply to comment #11)
> > Created an attachment (id=27701) [details] [details]
> > pleaset try the patch on your machine in KMS mode, thanks.
> >
> > please try the debug patch in KMS mode, then upload dmesg.
> > Then patch intends to print all modes from edid in KMS mode, which are
> > transmitted to X.
> The patch is for the linux kernel rigth?
> Currently I am doing tests with the LiveCD, I can compile the -intel driver and
> restart X from the LiveCD, but can't do that with the kernel.
> Unless Bryce make available a LiveCD with this kernel patch... :)

Hi Fabio
Because our issue is from KMS mode, the patch is for KMS.
It will help us to narrow down the issue, could you please try it or under Bryce's help :)

Thanks a lot
Ma Ling

Revision history for this message
In , Oibaf (oibaf) wrote :

Created an attachment (id=27724)
dmesg output with debug patch in KMS mode

OK, I installed karmic it to a new partition, applied the patch and recompiled the kernel.

dmesg output is attached. Note the last two lines were printed after a switch to VT and again to X.

Revision history for this message
In , Ling-ma (ling-ma) wrote :

Created an attachment (id=27839)
pleaset try the debug patch on your machine in KMS mode, thanks.

The patch intends to print all modes from edid and results from mode valid function in kms mode, through it we can find those mode line we transmitted to X server. please try it on your machine, then upload dmesg.

Thanks for your help.
Ma Ling

Revision history for this message
In , Oibaf (oibaf) wrote :

Created an attachment (id=27873)
dmesg output with second debug patch in KMS mode

Updated dmesg output is attached.

Revision history for this message
In , Ling-ma (ling-ma) wrote :

the root cause is stardard timing is not implemented in KMS, please try the patchset against latest drm-intel-next tree.
http://lists.freedesktop.org/archives/intel-gfx/2009-July/003560.html

thanks
Ma Ling

Revision history for this message
In , Ling-ma (ling-ma) wrote :

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

Revision history for this message
In , Ling-ma (ling-ma) wrote :

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

Revision history for this message
In , Oibaf (oibaf) wrote :

(In reply to comment #17)
> the root cause is stardard timing is not implemented in KMS, please try the
> patchset against latest drm-intel-next tree.
> http://lists.freedesktop.org/archives/intel-gfx/2009-July/003560.html

Where is drm-intel-next tree? If it's this:

git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel

then it fails to build here:

  CC [M] drivers/gpu/drm/drm_modes.o
drivers/gpu/drm/drm_modes.c: In function ‘drm_cvt_mode’:
drivers/gpu/drm/drm_modes.c:136: error: ‘gt’ undeclared (first use in this function)
drivers/gpu/drm/drm_modes.c:136: error: (Each undeclared identifier is reported only once
drivers/gpu/drm/drm_modes.c:136: error: for each function it appears in.)
drivers/gpu/drm/drm_modes.c:158: error: ‘amp’ undeclared (first use in this function)
...

Revision history for this message
In , Ling-ma (ling-ma) wrote :

please switch to drm-next tree(Dave Airlie <email address hidden>), the patch has been merged into it.
Thanks
Ma LIng

Revision history for this message
In , Oibaf (oibaf) wrote :

(In reply to comment #21)
> please switch to drm-next tree(Dave Airlie <email address hidden>), the patch has
> been merged into it.

OK, I switched to:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next
this compiles fine, however I still get the 1024x768 resolution in X (maybe with slight different vertical refresh).

Revision history for this message
In , Ling-ma (ling-ma) wrote :

(In reply to comment #22)
> (In reply to comment #21)
> > please switch to drm-next tree(Dave Airlie <email address hidden>), the patch has
> > been merged into it.
> OK, I switched to:
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next
> this compiles fine, however I still get the 1024x768 resolution in X (maybe
> with slight different vertical refresh).

please upload your latest xorg log file with modedebug option.

thanks

Revision history for this message
In , Oibaf (oibaf) wrote :

Created an attachment (id=28031)
Xorg log with KMS using linux drm-next 2009-07-24 and Option "ModeDebug" "true"

> please upload your latest xorg log file with modedebug option.

Xorg log is attached. This is my xorg.conf:

Section "Device"
        Identifier "Configured Video Device"
 Option "ModeDebug" "true"
EndSection

Section "Monitor"
        Identifier "Configured Monitor"
EndSection

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

Revision history for this message
In , Michael Fu (michael-fu-intel) wrote :

would you please try to apply patch in comment# 15 to dave's tree and post your dmesg? thanks.

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Will you please add the boot option of "drm.debug=0x6" on the lastest Dave's drm-next tree and see whether the issue still exits?
If it still exists, please attach the output of dmesg.
thanks.

Changed in xserver-xorg-video-intel:
status: Confirmed → In Progress
Revision history for this message
Peter T Hayward (energonic) wrote :

System: Intel Mac Mini (945GMA)
xserver-xorg-video-intel is now version 2.8.0-0ubuntu2
linux kernel is version 2.6.31-5-generic

I have a very similar problem but some details differ.

Karmic Alpha 3 Live CD boots by default into 800x600 (monitor is 1280x1024).
If I turn off KMS, by using kernel boot option 'i915.modeset=0', then it boots to correct 1280x1024.
(although there are log entries saying that this option is 'ignored' - perhaps it means KMS is ignored?)
Splash screen always has resolution 1280x1024 in either case.
The installed system behaves the same.

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

(In reply to comment #26)
> Will you please add the boot option of "drm.debug=0x6" on the lastest Dave's
> drm-next tree and see whether the issue still exits?
> If it still exists, please attach the output of dmesg.
> thanks.
Please use the following command to switch to the Dave's drm-next tree.
   1. git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
   2. git branch -r
   3. git checkout -b origin/drm-next

Thanks.

Revision history for this message
In , Oibaf (oibaf) wrote :

Created an attachment (id=28746)
dmesg output with second debug patch in KMS mode using drm-next tree up to cfcf4738cd6b5 (2009-08-13) and drm.debug=0x6 option

> Please use the following command to switch to the Dave's drm-next tree.
> 1. git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
> 2. git branch -r
> 3. git checkout -b origin/drm-next

These command don't work.

That's what I did:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
** git tree up to: cfcf4738cd6b5 drm: fixup include file in drm_encoder_slave 2009-08-13
git checkout --track -b drm-next origin/drm-next
patch -p1 < ../print_mode_line_in_kms.patch
** compiled kernel...
booted with kernel option drm.debug=0x6 (during boot it says that that option is unknown...)

Then I still get 1024x768. dmesg output is attached.

Revision history for this message
In , Oibaf (oibaf) wrote :

> dmesg output is attached.

Note that the first lines are missing, maybe because dmesg has a size limit.

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

(In reply to comment #29)
> > dmesg output is attached.
>
> Note that the first lines are missing, maybe because dmesg has a size limit.
>
Thanks for the testing.
From the Xorg.log it seems that the version of EDID is 1.1. In such case the standard timing level is DMT, which causes that it won't call the CVT/GTF to generate the required timing mode.
But in UMS mode it will also check whether the given parameter can be found in the default mode list and then return the correct mode.
Maybe we should also add the default mode list in KMS.
thanks.

Revision history for this message
In , Oibaf (oibaf) wrote :

> Maybe we should also add the default mode list in KMS.

Is this patch supposed to fix this issue?
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=882f0219518196a94cd2772004e87b178467139a

If not, is a patch planned?

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

(In reply to comment #31)
> > Maybe we should also add the default mode list in KMS.
>
> Is this patch supposed to fix this issue?
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=882f0219518196a94cd2772004e87b178467139a
>
> If not, is a patch planned?
It is not this patch.
I will attach it as soon as I finish it.

Thanks.
>

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Created an attachment (id=29099)
[Patch 1/2]: add the default mode table

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Created an attachment (id=29100)
[Patch 2/2]: it will first check whether the given standard mode can be found in default mode table

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Will you please try the attach two patches on Dave's drm-next tree and see whether the issue still exists?
How to get Dave's drm-next tree can be found in comment #27.
Thanks.

Revision history for this message
In , Oibaf (oibaf) wrote :

(In reply to comment #35)
> Will you please try the attach two patches on Dave's drm-next tree and see
> whether the issue still exists?
> How to get Dave's drm-next tree can be found in comment #27.
> Thanks.

It works fine now! X gets the right 1280x1024 resolution. The only problem, however, is that switching to VT is still slow, maybe because when booting or on VT Vf is 74,6~75Hz, while when on X Vf changes to 59,9Hz.

Revision history for this message
In , Oibaf (oibaf) wrote :

I also tried running openarena with the kernel with the two patches: the screen is completely out of sync (it moves horizontally very quickly), using a resolution of (according to my monitor OSD):
640x480, Hf 37KHz, Vf 72,6Hz.

When using standard Ubuntu kernel (KMS but 1024x768 X resolution) I get the right image, with a resolution of:
640x480, Hf 37KHz, Vf 72,8Hz.

Revision history for this message
In , Oibaf (oibaf) wrote :

I tried current drm-next where the patches were merged: the openarena problem is now fixed, however X still has a different refresh compared to boot and shutdown (both using Ubuntu usplash) and VT; also switching between VT and X require a mode change and is slow as without KMS.

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Thanks for the test.
From the test it seems that this bug can be resolved by the patches in comment #33/34.
As the following commit is already shipped in Dave's drm-next tree, this bug will be marked as resolved.

1. commit aa9eaa1f0962152d0bde821149d82fe7b70a6f92
Author: Zhao Yakui <email address hidden>
Date: Thu Sep 3 09:33:46 2009 +0800

    drm/kms: Add the default mode table

2. commit 559ee21d261a54c42594ef9405d27e9008eedf44
Author: Zhao Yakui <email address hidden>
Date: Thu Sep 3 09:33:47 2009 +0800

    drm/kms: try to find the std mode in DMT table

Revision history for this message
In , Oibaf (oibaf) wrote :

(In reply to comment #39)
> Thanks for the test.
> From the test it seems that this bug can be resolved by the patches in comment

Well, according to my test reported in comment #38 this bug should not be resolved ;) ... however since this bug is getting very long I opened a new bug report for the yet unfixed part:
https://bugs.freedesktop.org/show_bug.cgi?id=23833

Revision history for this message
Oibaf (oibaf) wrote :

This is partly fixed in drm-next now: X resolution is right, but X refresh is still different from the one set by the kernel, leading to slow X <-> VT switch.

I reported the refresh problem at:
https://bugs.freedesktop.org/show_bug.cgi?id=23833

Changed in xserver-xorg-video-intel:
status: In Progress → Fix Released
Revision history for this message
unggnu (unggnu) wrote :

This might be connected to Bug #435241 .
You may try the according Kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc1/ and check if the problem is gone with it. If so please mention it in my report.
Thanks.

Revision history for this message
Bryce Harrington (bryce) wrote :

From the discussion in the upstream bug, it appears they believe this to be a kernel issue that is now fixed. Can you confirm?

Meanwhile, since it appears to be a kernel issue I'm refiling it to linux.

affects: xserver-xorg-video-intel (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Triaged → New
tags: added: xorg-needs-kernel-fix
Revision history for this message
Oibaf (oibaf) wrote : Re: [Bug 392544] Re: [i945G] [intel KMS regression] wrong X resolution (fuzzy aspect match)

Citando Bryce Harrington <email address hidden>:

>> From the discussion in the upstream bug, it appears they believe this to
> be a kernel issue that is now fixed. Can you confirm?

Yes, that discussion was between an intel developer and me. I
confirmed the bug was partly (see my comment 13) fixed in drm-next,
which is now merged in 2.6.32.

Backporting the fix for karmic 2.6.31 should not be easy, since the
patch depended on other previous patches. Maybe all drm should be
backported.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Indeed the noted patches went in post 2.6.31. As an interim solution you can try running one of the latest mainline kernel builds which should contain these patches. For ex http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc4/

ogasawara@yoji:~/linux-2.6$ git show aa9eaa1f0962152d0bde821149d82fe7b70a6f92

commit aa9eaa1f0962152d0bde821149d82fe7b70a6f92

Author: Zhao Yakui <email address hidden>

Date: Thu Sep 3 09:33:46 2009 +0800

    drm/kms: Add the default mode table

ogasawara@yoji:~/linux-2.6$ git show 559ee21d261a54c42594ef9405d27e9008eedf44

commit 559ee21d261a54c42594ef9405d27e9008eedf44

Author: Zhao Yakui <email address hidden>

Date: Thu Sep 3 09:33:47 2009 +0800

    drm/kms: try to find the std mode in DMT table

Changed in linux (Ubuntu):
status: New → Triaged
Revision history for this message
Oibaf (oibaf) wrote :

> Indeed the noted patches went in post 2.6.31. As an interim solution
> you can try running one of the latest mainline kernel builds which
> should contain these patches. For ex http://kernel.ubuntu.com/~kernel-
> ppa/mainline/v2.6.32-rc4/

Yes, that's what I am doing now indeed.

Revision history for this message
dfernando (dfernando-neuf) wrote :

Hello
Got the same problem in kernel 2.6.31-17-generic Karmic with a Dell D630 Laptop.
USing a Dual Screen setup.
My laptop was ok. 1280 X 800
But the VGA was always using 1024x768.
[ 2.199142] [drm] DAC-6: set mode 1024x768

Nothing to do....
But, after installing 2.6.32 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc4/, the problem is resolved.
Thx

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Marking fix released for Lucid based on the last 2 comments.

-JFo

Changed in linux (Ubuntu):
status: Triaged → Fix Released
Changed in xserver-xorg-video-intel:
importance: Unknown → High
Changed in xserver-xorg-video-intel:
importance: High → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.