[GM45] Default 60Hz display mode drives LVDS incorrectly

[Chris Halse Rogers]

Binary package hint: xserver-xorg-video-intel

The latest version of xserver-xorg-video-intel fails to drive my laptop's LVDS display correctly at the default 60Hz refresh rate. It works fine at 50Hz.

Taking a screenshot reveals a normal desktop, so this is a problem somewhere in the scanout.

Attached photo shows the 60Hz display problem - bands of the display are stretched horizontally. It looks pretty cool!

ProblemType: Bug
Architecture: amd64
Date: Sat Jul 11 08:31:32 2009
DistroRelease: Ubuntu 9.10
MachineType: LENOVO 7465CTO
Package: xserver-xorg-video-intel 2:2.7.99.901+git20090702.74227141-0ubuntu1
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-2-generic root=/dev/mapper/Storage-Ubuntu--Root ro quiet splash crashkernel=384M-2G:64M,2G-:128M
ProcEnviron:
 PATH=(custom, user)
 LANG=en_AU.UTF-8
 SHELL=/bin/zsh
ProcVersionSignature: Ubuntu 2.6.31-2.16-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.5~rc4-1ubuntu3
 libdrm2 2.4.11-1ubuntu1
 xserver-xorg-video-intel 2:2.7.99.901+git20090702.74227141-0ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20090629.f39cafc5-0ubuntu1
SourcePackage: xserver-xorg-video-intel
Uname: Linux 2.6.31-2-generic x86_64
XorgConf: Error: [Errno 2] No such file or directory: '/etc/X11/xorg.conf'
dmi.bios.date: 04/22/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 6DET44WW (2.08 )
dmi.board.name: 7465CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6DET44WW(2.08):bd04/22/2009:svnLENOVO:pn7465CTO:pvrThinkPadX200s:rvnLENOVO:rn7465CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7465CTO
dmi.product.version: ThinkPad X200s
dmi.sys.vendor: LENOVO
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: x86_64kernel: 2.6.31-2-generic

[Geir Ove Myhr (gomyhr)]

Thank you for reporting this bug using the ubuntu-bug command. The information included helps us analyze this bug report better.

To make the analysis easier, could you remove the file .config/monitors.xml in your home directory? This is the file where custom mode setting for your user is stored. I don't see anything wrong with it, but it makes it easier to not have to take that file into account. Then I would like the Xorg.0.log produced when you log in next time without monitors.xml.

You mention that this happens with the latest version of xserver-xorg-video-intel (2:2.7.99.901+git20090702.74227141-0ubuntu1). Does that mean that it doesn't happen with the previous version?

Did you also upgrade the linux kernel recently? You have 2.6.31-2-generic and I seem to remember that the default was 2.6.31-1-generic until recently. Could you try to downgrade that as well to see if it changes anything (if you have an installed system, you probably have the old versions available in your boot menu)? The reason I'm asking is that the actual mode setting is now handled in the kernel (c.f. https://lists.ubuntu.com/archives/ubuntu-x/2009-June/000578.html) and if this problem was just introduced, it could have been through a kernel update.

A piece of information which may be useful to the developers is whether this also happens without kernel mode setting. To disable kernel mode setting add the boot parameter i915.modeset=0 to the kernel boot options. An Xorg.0.log and `xrandr --verbose` output from this case might be useful as well.

[Chris Halse Rogers (raof)]

> To make the analysis easier, could you remove the file
> .config/monitors.xml in your home directory? This is the file where
> custom mode setting for your user is stored. I don't see anything wrong
> with it, but it makes it easier to not have to take that file into
> account. Then I would like the Xorg.0.log produced when you log in next
> time without monitors.xml.
Attached. However, this corruption occurs at GDM time, before my
monitors.xml is read.

>
> You mention that this happens with the latest version of xserver-xorg-
> video-intel (2:2.7.99.901+git20090702.74227141-0ubuntu1). Does that mean
> that it doesn't happen with the previous version?
Correct. This behaviour appeared with the latest intel update.

>
> Did you also upgrade the linux kernel recently? You have
> 2.6.31-2-generic and I seem to remember that the default was
> 2.6.31-1-generic until recently. Could you try to downgrade that as well
> to see if it changes anything (if you have an installed system, you
> probably have the old versions available in your boot menu)? The reason
> I'm asking is that the actual mode setting is now handled in the kernel
> (c.f. https://lists.ubuntu.com/archives/ubuntu-x/2009-June/000578.html)
> and if this problem was just introduced, it could have been through a
> kernel update.
While there have been kernel updates, I didn't think the introduction of
this problem corresponded with an update. Indeed, I've just checked and
this behaviour occurs with 2.6.31-1-generic, too.

>
> A piece of information which may be useful to the developers is whether
> this also happens without kernel mode setting. To disable kernel mode
> setting add the boot parameter i915.modeset=0 to the kernel boot
> options. An Xorg.0.log and `xrandr --verbose` output from this case
> might be useful as well.
This does not appear with KMS disabled. I'll get those logs.

[Geir Ove Myhr (gomyhr)]

>> You mention that this happens with the latest version of xserver-xorg-
>> video-intel (2:2.7.99.901+git20090702.74227141-0ubuntu1). Does that mean
>> that it doesn't happen with the previous version?
> Correct.  This behaviour appeared with the latest intel update.

This is the most useful piece of information, since it narrows down
the possible commits that causes this. To spot any differences it
would be great with Xorg.0.log and `xrandr --verbose` output with the
previous xserver-xorg-video-intel (which probably still is in your
/var/lcache/apt/archives).

[Chris Halse Rogers (raof)]

Logs when running with the correctly working 2:2.7.99.1
+git20090602.ec2fde7c-0ubuntu5 attached.

[Bryce Harrington (bryce)]

Created an attachment (id=27664)
Image054.jpg

Forwarding this bug from Ubuntu reporter Chris Halse Rogers:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/398026

[Problem]
Recently for LVDS, the driver sometimes chooses a mode with the preferred resolution but with an inappropriate frequency (60 Hz instead of 50 Hz).

A similar bug (believed to be a dupe) with 85 Hz being selected instead of the more correct 60 Hz is here:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/396171

[Original Report]
The latest version of xserver-xorg-video-intel fails to drive my laptop's LVDS display correctly at the default 60Hz refresh rate. It works fine at 50Hz.

Taking a screenshot reveals a normal desktop, so this is a problem somewhere in the scanout.

Attached photo shows the 60Hz display problem - bands of the display are stretched horizontally. It looks pretty cool!

The previous version of xserver-xorg-video-intel (...git20090602) had a bug in which only the preferred mode from the EDID information would be available (https://bugs.freedesktop.org/show_bug.cgi?id=20801). In ...git20090702 this bug is fixed and also other modes are available. The problem seems to be that for LVDS output the driver sometimes chooses a mode with the preferred resolution, but with a higher frequency (85 Hz instead of 60 Hz in bug 396171 and 60 Hz instead of 50 Hz in bug 398026).

ProblemType: Bug
Architecture: amd64
Date: Sat Jul 11 08:31:32 2009
DistroRelease: Ubuntu 9.10
MachineType: LENOVO 7465CTO
Package: xserver-xorg-video-intel 2:2.7.99.901+git20090702.74227141-0ubuntu1
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-2-generic root=/dev/mapper/Storage-Ubuntu--Root ro quiet splash crashkernel=384M-2G:64M,2G-:128M
ProcEnviron:
 PATH=(custom, user)
 LANG=en_AU.UTF-8
 SHELL=/bin/zsh
ProcVersionSignature: Ubuntu 2.6.31-2.16-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.5~rc4-1ubuntu3
 libdrm2 2.4.11-1ubuntu1
 xserver-xorg-video-intel 2:2.7.99.901+git20090702.74227141-0ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20090629.f39cafc5-0ubuntu1
SourcePackage: xserver-xorg-video-intel
Uname: Linux 2.6.31-2-generic x86_64
XorgConf: Error: [Errno 2] No such file or directory: '/etc/X11/xorg.conf'
dmi.bios.date: 04/22/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 6DET44WW (2.08 )
dmi.board.name: 7465CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6DET44WW(2.08):bd04/22/2009:svnLENOVO:pn7465CTO:pvrThinkPadX200s:rvnLENOVO:rn7465CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7465CTO
dmi.product.version: ThinkPad X200s
dmi.sys.vendor: LENOVO
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: x86_64kernel: 2.6.31-2-generic

[Bryce Harrington (bryce)]

Created an attachment (id=27665)
CurrentDmesg.txt

[Bryce Harrington (bryce)]

Created an attachment (id=27666)
XorgLog.txt

[Bryce Harrington (bryce)]

Created an attachment (id=27667)
Xrandr.txt

[Bryce Harrington (bryce)]

Hi Chris, I've forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=22761 and CC'd you to the bug. Please follow up any info or testing requests they have there.

[Geir Ove Myhr (gomyhr)]

I didn't ask for Xorg.0.log with ModeDebug enabled, because it seems to make no difference with KMS. Is this correct?

[Geir Ove Myhr (gomyhr)]

Chris, does the monitor start up at 60 Hz right away? In the xrandr-output the monitor attach in the first comment and in the upstream report the monitor runs at 50 Hz. If you set the frequencey to 50 Hz, does it set itself back to 60 Hz. Oded reports that undocking the laptop, attaching an extrenal monitor and waking the monitor from sleep would reset the frequency to 85 Hz. Do you have any similar observations?

[yakuizhao (yakui-zhao)]

Created an attachment (id=27702)
try the debug patch in which the DPLL MD reg is updated only for SDVO device

Will you please try the debug patch on the latest kernel(2.6.31-rc3) and see whether the issue still exists?
    In the debug patch it will write the DPLL MD reg only when the output type is SDVO device.

It will be great if you can confirm whether the issue can be reproduced in UMS mode.

Thanks.

[Chris Halse Rogers (raof)]

 status fixreleased

I can no longer reproduce this; it seems fixed. I'm not sure whether it
was fixed by yesterday's xserver-xorg-video-intel 2:2.7.99.901
+git20090702.74227141-0ubuntu1 upload or the new kernel today, but I no
longer get scanout corruption when running at 60Hz, so it no longer
matters that 60Hz is the default mode!

I'll wander upstream and close it there, too.

[yakuizhao (yakui-zhao)]

From the description it seems that the LVDS can work well if the refresh rate is 50Hz. But when the refresh rate is 60, it can't work well. Right?
How do you change the refresh rate? In the boot phase or by using xrandr?
From the log it seems that the preferred mode is 1440x900*50 for the LVDS. In such case it will choose the 50HZ display mode.

Will you please also confirm whether this issue can be reproduced in UMS mode? (Adding the boot option of "i915.modeset=0").

Thanks.

[Geir Ove Myhr (gomyhr)]

The version of xserver-xorg-video-intel hasn't changed since you reported the bug, but the new kernel is based on 2.6.31-rc3 instead of -rc2 and therefore probably has various fixes.

[yakuizhao (yakui-zhao)]

Will you please try the debug patch on the latest kernel(2.6.31-rc3) and see whether the issue still exists?
In the debug patch it will write the DPLL MD reg only when the output type is SDVO.
Thanks.

[yakuizhao (yakui-zhao)]

I have another issue.
From the log it seems that there exists the EDID for LVDS device. And the 1440x900*50 mode is the preferred mode. In such case how is the mode(1440x900*59.9) also added to the mode list?
Thanks.

[Chris Halse Rogers (raof)]

This bug is definitely resolved by the 2.6.31-3-generic kernel, which is based on 2.6.31-rc3. Booting back into the -2-generic kernel exhibits the corruption, booting into 2.6.31-3-generic doesn't, even when running the LVDS at 60Hz.

@yakuizhao: Do you still want output from that debug patch?

[Oded Arbel (oded-geek)]

I also am not seeing corruption issues with the kernel update (I checked before and after and the kernel update indeed seems to be the reason).

The screen still changes refresh rate when going into and out of docking, but now all modes look fine.

[Geir Ove Myhr (gomyhr)]

Chris and Oded, it's good that the corruption is gone, but the frequency should not change sporadically as at least Oded is reporting. Unless told otherwise, the driver should choose the frequency of the preferred EDID mode, and as far as I can see this is 50 Hz for Chris and 60 Hz for Oded. It would be nice if you could help troubleshooting this even though the corruption caused by the wrong frequency is gone.

[Oded Arbel (oded-geek)]

Sure, no probs - just let me know how can I help.

[yakuizhao (yakui-zhao)]

Hi, Oded/Chris
    Will you please try the debug patch in comment #12 on the 2.6.31.2 generic kernel and see whether the issue can be reproduced?
   Thanks.

[Geir Ove Myhr (gomyhr)]

On Wed, Jul 15, 2009 at 9:02 PM, yakuizhao<email address hidden> wrote:
>    Will you please try the debug patch in comment #12 on the 2.6.31.2 generic kernel and see whether the issue can be reproduced?

@Yakui: The remaining issue is that the frequency is higher than the
preferred mode, right? Do you want 2.6.31-2-generic tested instead of
2.6.31-3-generic?

@Oded/Chris: Are you able to build a patched kernel or would you like
help with that?

[yakuizhao (yakui-zhao)]

Hi, Geir
    What you said is right. I hope that it is tested on the 2.6.31.2 instead of 2.6.31.3.
    The remaining issue is why we can add the mode like 1440x900*60. It is very interesting.
    I check the code and find that it is not parsed from EDID. And it is not defined in the default mode table. I don't know where to add it.
    Thanks.

[Oded Arbel (oded-geek)]

I've added the patch to 2.6.31-3-generic and there is no change in behavior (although I think its crashing a bit - but I can't reproduce reliably).

I'll patch 2.6.31-2 and get back to you with more info (compiling takes a long time ;-) ).

[Oded Arbel (oded-geek)]

I can't find the source package for 2.6.31-2 - packages.ubuntu.com only has 2.6.31-3 and 2.6.30 or older.

Can you please direct me to where I can find ubuntu sources for 2.6.31-2 that I can patch and install?

[Geir Ove Myhr (gomyhr)]

https://launchpad.net/ubuntu/+source/linux/2.6.31-2.17

The full list of published source packages is at
https://launchpad.net/ubuntu/+source/linux .

[Oded Arbel (oded-geek)]

I applied the patch to the above mentioned kernel and run it. Curiously it does not feature the screen corruption that was the issue of this bug, but it does still changes to 85Hz when docked and back to 60Hz when undocked:

Docked:
$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 287mm x 215mm
   1024x768 60.0 + 85.0* 75.0 70.1 60.0 50.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
DVI1 disconnected (normal left inverted right x axis y axis)

Undocked:
$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 287mm x 215mm
   1024x768 60.0*+ 85.0 75.0 70.1 60.0* 50.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
DVI1 disconnected (normal left inverted right x axis y axis)

Syslog has this to day when docking:
Jul 22 18:02:59 sepiroth kernel: [ 177.915766] usb 1-4: new high speed USB device using ehci_hcd and address 6
Jul 22 18:02:59 sepiroth kernel: [ 178.124472] usb 1-4: configuration #1 chosen from 1 choice
Jul 22 18:02:59 sepiroth kernel: [ 178.244951] hub 1-4:1.0: USB hub found
Jul 22 18:02:59 sepiroth kernel: [ 178.245074] hub 1-4:1.0: 4 ports detected
Jul 22 18:02:59 sepiroth kernel: [ 178.328126] [drm] LVDS-8: set mode 18
Jul 22 18:02:59 sepiroth kernel: [ 323.704995] ACPI: \_SB_.GDCK - undocking
Jul 22 18:02:59 sepiroth kernel: [ 323.908261] usb 1-4: USB disconnect, address 6
Jul 22 18:02:59 sepiroth kernel: [ 324.627003] [drm] LVDS-8: set mode 19
Jul 22 18:02:59 sepiroth kernel: [ 365.583521] [drm] LVDS-8: set mode 1a
Jul 22 18:02:59 sepiroth kernel: [ 381.548982] ACPI: \_SB_.GDCK - docking

But doesn't say anything when undocking. the mode numbers listed are incremented each time I dock, so the next modes will be 1b, 1c and 1d.

[Michael Fu (michael-fu-intel)]

ping~

[Geir Ove Myhr (gomyhr)]

ykzhao wandered downstream and there are some answers there. I'm summarizing:
- the corruption is gone with kernel 2.6.31-rc3, but the monitor is still driven at a frequency which is higher than what it should be according to the EDID information
- When the patch in comment #5 was applied to 2.6.31-rc2 the corruption went away, but the wrong frequency problem remained.

Oded, who has 85 Hz instead of 60 Hz reports the following intersting behaviour when docking and undocking his laptop: (citing in the rest of this comment)

I applied the patch to the above mentioned kernel and run it. Curiously it does not feature the screen corruption that was the issue of this bug, but it does still changes to 85Hz when docked and back to 60Hz when undocked:

Docked:
$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 287mm x 215mm
   1024x768 60.0 + 85.0* 75.0 70.1 60.0 50.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
DVI1 disconnected (normal left inverted right x axis y axis)

Undocked:
$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 287mm x 215mm
   1024x768 60.0*+ 85.0 75.0 70.1 60.0* 50.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
DVI1 disconnected (normal left inverted right x axis y axis)

Syslog has this to day when docking:
Jul 22 18:02:59 sepiroth kernel: [ 177.915766] usb 1-4: new high speed USB device using ehci_hcd and address 6
Jul 22 18:02:59 sepiroth kernel: [ 178.124472] usb 1-4: configuration #1 chosen from 1 choice
Jul 22 18:02:59 sepiroth kernel: [ 178.244951] hub 1-4:1.0: USB hub found
Jul 22 18:02:59 sepiroth kernel: [ 178.245074] hub 1-4:1.0: 4 ports detected
Jul 22 18:02:59 sepiroth kernel: [ 178.328126] [drm] LVDS-8: set mode 18
Jul 22 18:02:59 sepiroth kernel: [ 323.704995] ACPI: \_SB_.GDCK - undocking
Jul 22 18:02:59 sepiroth kernel: [ 323.908261] usb 1-4: USB disconnect, address 6
Jul 22 18:02:59 sepiroth kernel: [ 324.627003] [drm] LVDS-8: set mode 19
Jul 22 18:02:59 sepiroth kernel: [ 365.583521] [drm] LVDS-8: set mode 1a
Jul 22 18:02:59 sepiroth kernel: [ 381.548982] ACPI: \_SB_.GDCK - docking

But doesn't say anything when undocking. the mode numbers listed are incremented each time I dock, so the next modes will be 1b, 1c and 1d.

[yakuizhao (yakui-zhao)]

Hi, Oded
     Do you mean that corruption disappears after applying the patch on the 2.6.31-rc2? Right?
    thanks.

[yakuizhao (yakui-zhao)]

Hi, Chris
     How about your test result?
    Thanks.

[Oded Arbel (oded-geek)]

With the patch applied to 2.6.31.2 , I could not reproduce the screen corruption problem that is the original complaint of this ticket.

I could not reproduce it ever since I did an upgrade that installed kernel 2.6.31.3, so on the face of it it looks like another update, and not the kernel upgrade, fixed the problem.

[yakuizhao (yakui-zhao)]

Will you please attach the output of cat /sys/class/drm/card0-LVDS*/modes ?
Thanks.

[Oded Arbel (oded-geek)]

$ cat /sys/class/drm/card0-LVDS*/modes
1024x768
1024x768

[yakuizhao (yakui-zhao)]

Will you please also attach the xorg.log with KMS disabled?
Thanks.

[Oded Arbel (oded-geek)]

Sorry about the late reply - I'm moving to a new apartment and haven't got much time. It took me a while to figure out what is KMS, and then to try to disable it. When I add i915.modeset=0 to the kernel command line, it complains that its an unknown boot option and modinfo shows no such parameter supported by the i915 module.

for some reason I can't remove i915 in order to reinstall it with the option on the command line (it complains that the module is in use even if I shutdown everything X), so I added a modprobe config file in a final effort to turn it off. I'm not sure that it did anything and I don't know how to verify, but the output of LVDS modes is identical.

[Geir Ove Myhr (gomyhr)]

Oded, I also get a complaint that i915.modeset=0 is an unknown boot option when adding it to the kernel command line. It still disables KMS, though.

The reason that you cannot remove i915 while the system is running is that the module is responsible for _all_ modesetting on the system, not only for X. This is one of its advantages - all the mode setting is coordinated from one piece of code. On my computer the VT fonts are different when KMS is enabled. One easy (but probably not standard) way of recognizing if KMS is used is to look at the display names in the output of xrandr and Xorg.0.log. UMS (Userland mode setting) uses names like LVDS, VGA, VGA-1, etc. but KMS uses LVDS1, VGA1, etc. There's probably something in dmesg output that gives away KMS as well.

Even if you don't see any difference with UMS (i.e. KMS disabled), Xorg.0.log and the xrandr output for that case may be useful for someone who knows what to look for.

[Oded Arbel (oded-geek)]

Ok, I used the kernel command line param and indeed the display names are as you specified. When KMS is disabled, there is no /sys/class/drm/card0-LVDS*/modes file.

Here's the output of xrandr:
$ xrandr --verbose
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA disconnected (normal left inverted right x axis y axis)
 Identifier: 0x3b
 Timestamp: 19619
 Subpixel: unknown
 Clones:
 CRTCs: 0 1
 Transform: 1.000000 0.000000 0.000000
             0.000000 1.000000 0.000000
             0.000000 0.000000 1.000000
            filter:
LVDS connected 1024x768+0+0 (0x3e) normal (normal left inverted right x axis y axis) 287mm x 215mm
 Identifier: 0x3c
 Timestamp: 19619
 Subpixel: horizontal rgb
 Clones:
 CRTC: 1
 CRTCs: 1
 Transform: 1.000000 0.000000 0.000000
             0.000000 1.000000 0.000000
             0.000000 0.000000 1.000000
            filter:
 EDID_DATA:
  00ffffffffffff0030ae204000000000
  23110103801d1578ea6f959c544c8726
  21505400000001010101010101010101
  01010101010164190040410026301888
  36001fd7100000182815004041002630
  188836001fd7100000180000000f0061
  43326143280f010030640053000000fe
  004c544431343145434d420a202000e9
 PANEL_FITTING: full_aspect
  supported: center full_aspect full
 BACKLIGHT_CONTROL: kernel
  supported: native legacy combination kernel
 BACKLIGHT: 15 (0x0000000f) range: (0,15)
  1024x768 (0x3e) 65.0MHz -HSync -VSync *current +preferred
        h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz
        v: height 768 start 771 end 777 total 806 clock 60.0Hz
  1024x768 (0x3f) 94.5MHz +HSync +VSync
        h: width 1024 start 1072 end 1168 total 1376 skew 0 clock 68.7KHz
        v: height 768 start 769 end 772 total 808 clock 85.0Hz
  1024x768 (0x40) 78.8MHz +HSync +VSync
        h: width 1024 start 1040 end 1136 total 1312 skew 0 clock 60.0KHz
        v: height 768 start 769 end 772 total 800 clock 75.0Hz
  1024x768 (0x41) 75.0MHz -HSync -VSync
        h: width 1024 start 1048 end 1184 total 1328 skew 0 clock 56.5KHz
        v: height 768 start 771 end 777 total 806 clock 70.1Hz
  1024x768 (0x3e) 65.0MHz -HSync -VSync *current
        h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz
        v: height 768 start 771 end 777 total 806 clock 60.0Hz
  1024x768 (0x42) 54.2MHz -HSync -VSync
        h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 40.3KHz
        v: height 768 start 771 end 777 total 806 clock 50.0Hz
  832x624 (0x43) 57.3MHz -HSync -VSync
        h: width 832 start 864 end 928 total 1152 skew 0 clock 49.7KHz
        v: height 624 start 625 end 628 total 667 clock 74.6Hz
  800x600 (0x44) 56.3MHz +HSync +VSync
        h: width 800 start 832 end 896 total 1048 skew 0 clock 53.7KHz
        v: height 600 start 601 end 604 total 631 clock 85.1Hz
  800x600 (0x45) 50.0MHz +HSync +VSync
        h: width 800 start 856 end 976 total 1040 skew 0 clock 48.1KHz
        v: height...

[Oded Arbel (oded-geek)]

With KMS disabled, the screen also no longer changes refresh rates when docking and undocking.

I'll enable KMS and check if I can reproduce the refresh rate change again.

[yakuizhao (yakui-zhao)]

Please attach the Xorg.log when kms is disabled by adding the boot option of "i915.modeset=0".
thanks.

[yakuizhao (yakui-zhao)]

Created an attachment (id=28612)
add the detailed mode debug info related with the output

Will you please try the debug patch on the xserver and do the test on the 2.6.31-rc2 kernel?
After the system is booted, please attach the output of xorg.log.
Thanks.

[yakuizhao (yakui-zhao)]

Sorry for the late response.
The remaining issue is that the monitor is still driven at a frequency which is higher than what it should be according to the EDID information.

Will you please try the debug patch on the latest xserver and do the test on the 2.6.31-rc2/3 kernel?
After the system is booted, please attach the output of xorg.log.
Thanks.

[yakuizhao (yakui-zhao)]

Will you please try the debug patch on the latest xserver and do the test on the 2.6.31-rc3 kernel?
After the system is booted, please attach the xorg.log.
Thanks.

[Michael Fu (michael-fu-intel)]

ping Chris...

[yakuizhao (yakui-zhao)]

    The patch is already shipped in Eric's drm-intel-next tree.
commit bb66c5122b4300b475b585fffb811311f39f5431
Author: Zhao Yakui <email address hidden>
Date: Thu Sep 10 15:45:49 2009 +0800

    drm/i915: Write zero to DPLL_MD Reg for non-SDVO output

    From the test in comment #7 it seems that this issue can't be reproduced on the failing kernel(2.6.31-rc2). So this bug will be marked as resolved.

At the same time there exists the second issue that the monitor is still driven at a frequency which is higher than what it should be according to the EDID information. But there is no response from the bug reporter.

If the second issue still exists, please open a new bug and attach the xorg.0.log after applying the patch in comment #8.

thanks.