[i945GM] xrandr cycling is all messed up with KMS

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

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

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

please upload your xorg.conf file in KMS mode.

Thanks
Ma Ling

(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.

(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

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..

(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.

(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.

(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.

> 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

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

(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... :)

(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

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.

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

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

Updated dmesg output is attached.

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

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

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

(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)
...

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

(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).

(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

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

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

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.

(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.

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.

> dmesg output is attached.

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

(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.

> 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?

(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.
>

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

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

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.

(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.

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.

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.

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

(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