Ubuntu
xserver-xorg-video-intel package

raring: corrupted display on LVDS when I disconnect my HDMI output

Bug #1155838 reported by Steve Langasek
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Medium
linux (Ubuntu)
Invalid
Undecided
Unassigned
xserver-xorg-video-intel (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Today, I tried to undock my laptop to enjoy the nice weather outside. I was surprised to find that the moment I did so, the display on the LVDS output was corrupted.

The moment I reconnected the HDMI display, the output on LVDS was normal again.

Disconnecting the HDMI again, or manually reconfiguring outputs with gnome-control-center, the problem is reproducible. HDMI on, LVDS display is sane. HDMI off, LVDS output is garbled (looking like wrong striping or wrong interlacing or something).

$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1850, maximum 32767 x 32767
LVDS1 connected 1280x800+400+1050 (normal left inverted right x axis y axis) 261mm x 163mm
   1280x800 60.0*+ 50.0
   1024x768 60.0
   800x600 60.3 56.2
   640x480 59.9
VGA1 disconnected (normal left inverted right x axis y axis)
   1680x1050 60.0
   1280x800 60.0
HDMI1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 473mm x 296mm
   1680x1050 60.0*+
   1280x1024 75.0 60.0
   1440x900 75.0 59.9
   1280x960 60.0
   1280x800 59.9
   1152x864 75.0
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 72.8 75.0 66.7 60.0
   720x400 70.1
DP1 disconnected (normal left inverted right x axis y axis)

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: xserver-xorg-video-intel 2:2.21.4-0ubuntu1
Uname: Linux 3.9.0-030900rc2-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.9.1-0ubuntu1
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,imgpng,snap,place,grid,resize,regex,mousepoll,gnomecompat,unitymtgrabhandles,vpswitch,move,animation,expo,session,wall,ezoom,staticswitcher,workarounds,fade,scale,unityshell]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
Date: Fri Mar 15 16:24:00 2013
DistUpgraded: 2013-01-25 08:16:10,776 WARNING no activity on terminal for 300 seconds (Configuring texlive)
DistroCodename: quantal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, including running git bisection searches
GraphicsCard:
 Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:215a]
InstallationDate: Installed on 2010-09-24 (903 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
MachineType: LENOVO 3249CTO
MarkForUpload: True
PlymouthDebug: Error: [Errno 13] Permission denied: '/var/log/plymouth-debug.log'
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.9.0-030900rc2-generic root=/dev/mapper/hostname-root ro quiet splash --verbose vt.handoff=7
SourcePackage: xserver-xorg-video-intel
UpgradeStatus: Upgraded to quantal on 2013-01-25 (49 days ago)
dmi.bios.date: 08/23/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET52WW (1.22 )
dmi.board.name: 3249CTO
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:bvr6QET52WW(1.22):bd08/23/2010:svnLENOVO:pn3249CTO:pvrThinkPadX201:rvnLENOVO:rn3249CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 3249CTO
dmi.product.version: ThinkPad X201
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.9~daily13.03.08-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.42-0ubuntu2
version.libgl1-mesa-dri: libgl1-mesa-dri 9.0.2-0ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.0.2-0ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.13.2-0ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.1.0-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.21.4-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.6-0ubuntu3
xserver.bootTime: Fri Mar 15 00:29:32 2013
xserver.configfile: /etc/X11/xorg.conf
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.13.2-0ubuntu3
xserver.video_driver: intel

Revision history for this message
Steve Langasek (vorlon) wrote :
Revision history for this message
Steve Langasek (vorlon) wrote :

Undocked again just now to try to take a picture, and the problem did not recur; so it's an intermittent problem.

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

First of all, you can get rid of your xorg.conf, or simplify it down to just the DontZap option. All of that should be irrelevant to this problem, but may as well exclude it.

Next, your MonitorsUser.xml looks a bit odd; the last config (which I assume is the one gnome is using for your HW since it's the only one with HDMI1) is missing configuration details on LVDS1. So, I'd try removing monitors.xml and reconfiguring in gnome. See if it generates the same (I guess invalid?) config.

The thing to do here is to study xrandr --verbose output before and after the hotplug event. The attached xrandr data I guess is from with the HDMI1 connected:

HDMI1 connected 1680x1050+0+0 (0x4c) normal (normal left inverted right x axis y axis) 473mm x 296mm
LVDS1 connected (normal left inverted right x axis y axis)

When the laptop's in the broken state, check what the xrandr output looks like.

I notice you're running a non-standard kernel. Assuming this issue is a regression and not just a misbehavior you've had but haven't noticed, then that kernel would probably be the first thing to look at (i.e. try a different kernel version and see if it reproduces). All the modesetting is done in the kernel so bugs relating to monitor output often arise from that. I've added a kernel task.

However, this actually feels more like a gnome bug. gnome-settings-daemon (or rather, libgnome-desktop) is what handles the hotplugging event and what remaps crtcs to appropriate outputs. Turn on verbose debugging for that and collect the debugging output before/during/after the hotplug event to see exactly what xrandr events are occurring. That shows what CRTCs are being mapped to what outputs. Often with these types of "output goes missing and just displays corruption" issues, the wrong crtc is mapped to the wrong output device.

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Incomplete
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
tags: added: raring
Revision history for this message
Chris Wilson (ickle) wrote :

If you can grab a photo of the corruption as well that's usually very helpful in identifying the source of the problem.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1155838] Re: raring: corrupted display on LVDS when I disconnect my HDMI output

On Sat, Mar 16, 2013 at 08:33:09AM -0000, Chris Wilson wrote:
> If you can grab a photo of the corruption as well that's usually very
> helpful in identifying the source of the problem.

Yep - unfortunately I docked to file the bug report, and when I undocked
again it was no longer reproducible for me to take a picture of.

Verbally, I would describe it as trying to look at my windows through
half-closed blinds.

bugbot (bugbot)
tags: added: corruption
tags: added: tv-out
Revision history for this message
Greg A (etulfetulf) wrote :

I suspect this is a duplicate of Bug #1157678

Revision history for this message
Steve Langasek (vorlon) wrote :

On Fri, Mar 22, 2013 at 07:05:07PM -0000, Greg Auger wrote:
> I suspect this is a duplicate of Bug #1157678

Yes, the corruption pattern is similar. I can't say with certainty that
it's the same bug.

Since that bug has an upstream commit fixing it, I'll give that a try here.

Revision history for this message
In , Chris J Arges (arges) wrote :

Created attachment 77747
Glitchy Output

If I attach an external monitor to my Lenovo Thinkpad T420 and type the following command:
    xrandr --output VGA1 --auto --primary --output LVDS1 --off
I get glitchy output as shown in the attached picture.

I have tested with a pre-built Ubuntu kernel here:
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/
This should be commit bae3699182027525d92b97d904578a533264b242 from the drm-intel tree next branch.

The related launchpad bug is here:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1157678

While https://bugs.freedesktop.org/show_bug.cgi?id=57160 is linked in the bug, I believe this is another issue. I've tested with a kernel that contains the patch and it did not fix the issue.

My graphics card is:
2nd Generation Core Processor Family Integrated Graphics Controller [8086:116]

Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

Ah, a victim for testing a few patches of mine!

Please test the pll-limits-mess branch from http://cgit.freedesktop.org/~danvet/drm

Revision history for this message
In , Chris J Arges (arges) wrote :

Daniel,
I've tested with the pll-limits-mess branch, and it resulted in the same output.

Revision history for this message
Steve Langasek (vorlon) wrote :

This was thought to be a duplicate of bug #1157678, but that bug has been marked fixed upstream and this bug is still reproducible.

Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Medium
Revision history for this message
In , Chris Wilson (ickle) wrote :

Can you please attach a drm.debug=6 dmesg and Xorg.log from the latest run? Also the output of intel_reg_dumper would be useful.

Revision history for this message
Steve Langasek (vorlon) wrote :

regarding comment #3 from Bryce, the monitors.xml is not an issue here; I've moved this aside and still been able to reproduce it, and I've reproduced this also with a completely clean guest account.

It is not specific to the mainline kernel; it's reproducible both with the raring kernel and with the other (Ubuntu) test kernels I was running.

I'm attaching two files, xrandr-good.txt and xrandr-bad.txt, for xrandr --verbose output with and without corruption respectively. In the 'bad' case, the corruption appears on the HDMI output - but this is not always true; it may appear on one output or the other.

I can't say I see anything that points to this being a gnome bug, as I can reproduce the problem when calling xrandr directly to set the mode ('xrandr --output LVDS1 --pos 1680x0').

Revision history for this message
Steve Langasek (vorlon) wrote :
Revision history for this message
In , Chris J Arges (arges) wrote :

Created attachment 77782
dmesg (drm.debug=6)

Revision history for this message
In , Chris J Arges (arges) wrote :

Created attachment 77783
Xorg.0.log

Revision history for this message
In , Chris J Arges (arges) wrote :

Created attachment 77784
intel_reg_dump

Revision history for this message
In , Chris Wilson (ickle) wrote :

And the other one is 'cat /sys/kernel/debug/dri/0/i915_gem_framebuffers'

Revision history for this message
In , Chris J Arges (arges) wrote :

Created attachment 77787
i915_gem_framebuffer

Bug Watch Updater (bug-watch-updater)
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Chris Wilson (ickle) wrote :

So what I thought might have been happening was that we reused an incorrectly sized cached framebuffer. Not so sure after reading i915_gem_framebuffer. However, I've implemented a defense against using the wrong framebuffer size:

commit 9dae6f9f1f169c228929185a8bd94e82afe92574
Author: Chris Wilson <email address hidden>
Date: Fri Apr 12 11:01:08 2013 +0100

    sna: Flush the scanout cache after resizing the display

    And ensure that any new scanout allocations make the requested size.

It will be worth updating xf86-video-intel.git and seeing if that makes any difference (will be in ppa:xorg-edgers in a few hours).

Revision history for this message
In , Chris J Arges (arges) wrote :

Building and installing latest xf86-video-intel.git with HEAD: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=f0b6ae2cfb811a8c234634c878800ca1fb95703f

Seems to resolve the issue, I've tested the original issue of unplugging and plugging in an external monitor, suspending and resuming, and also the xrandr trigger. So far no screen corruption!

Bug Watch Updater (bug-watch-updater)
Changed in xserver-xorg-video-intel:
status: Confirmed → Fix Released
Chris Wilson (ickle)
Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Fix Committed
Revision history for this message
Bryce Harrington (bryce) wrote :

The patch listed as a fix for this issue in the upstream bug has been uploaded for ubuntu raring. Since it sounds like that should fix this issue I'm closing this bug. If it proves to still be reproducible, reopen the bug.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Fix Committed → Fix Released
Steve Langasek (vorlon)
Changed in linux (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Chris Wilson (ickle) wrote :

Steve, there is a known (and fixed in 3.9) bug in the kernel as well with exactly the same symptoms.

Changed in linux (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

But this bug report is not about an arbitrary set of bugs that produce the same symptoms; it's about corruption seen on *my* laptop, corruption that did not clear up when I tested the kernel fix - which is why I un-duped this bug from bug #1157678.

It *is* fixed with the current version of xserver-xorg-video-intel in raring. So as far as I'm concerned, the issue is resolved, and keeping a task on the linux package open on this bug is of no help to anyone.

Changed in linux (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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