[arrandale] desktop is messed up with external monitors (x86_64)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| xf86-video-intel |
Fix Released
|
Medium
|
||
| linux (Ubuntu) |
High
|
Timo Aaltonen | ||
| Precise |
High
|
Timo Aaltonen | ||
| xserver-xorg-video-intel (Ubuntu) |
Medium
|
Unassigned | ||
| Natty |
Undecided
|
Unassigned | ||
| Precise |
Medium
|
Unassigned |
Bug Description
Binary package hint: unity
(I'm not sure where in the stack this problem really is, so I'm guessing and picking on unity)
I have a Lenovo T410s laptop with Intel graphics and I use it with a dock with two 1920x1200 monitors connected. I'm running up-to-date Natty. If I boot the laptop with it already docked, everything works perfectly: the two external monitors are used and I get a nice unity desktop spanning my 3840x1200 space.
However, if I boot with the laptop undocked, log in, and then dock the laptop, it breaks pretty badly. Only one monitor is lit up, and I just get a black screen with a mouse pointer there -- no desktop background, windows, toolbars, or anything. Once it's in this state, it doesn't seem possible to recover -- if I undock the laptop again, the internal screen just stays black with a pointer.
When the laptop is in a working state, undocking it sort of works... the desktop switches to the laptop screen, but then redocking it acts just like docking as described above.
ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: unity 3.6.8-0ubuntu3
ProcVersionSign
Uname: Linux 2.6.38-7-generic x86_64
Architecture: amd64
CompizPlugins: [core,bailer,
CompositorRunning: compiz
DRM.card0.DP.1:
status: disconnected
enabled: disabled
dpms: Off
modes:
edid-base64:
DRM.card0.DP.2:
status: disconnected
enabled: disabled
dpms: Off
modes:
edid-base64:
DRM.card0.DP.3:
status: disconnected
enabled: disabled
dpms: Off
modes:
edid-base64:
DRM.card0.HDMI.A.1:
status: disconnected
enabled: disabled
dpms: Off
modes:
edid-base64:
DRM.card0.HDMI.A.2:
status: connected
enabled: enabled
dpms: On
modes: 1920x1200 1920x1080 1920x1080 1600x1200 1680x1050 1400x1050 1280x1024 1280x1024 1440x900 1360x768 1152x864 1280x720 1280x720 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 720x576 720x480 640x480 640x480 640x480 640x480 720x400
edid-base64: AP/////
DRM.card0.HDMI.A.3:
status: connected
enabled: enabled
dpms: On
modes: 1920x1200 1920x1080 1920x1080 1600x1200 1680x1050 1400x1050 1280x1024 1280x1024 1440x900 1360x768 1152x864 1280x720 1280x720 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 720x576 720x480 640x480 640x480 640x480 640x480 720x400
edid-base64: AP/////
DRM.card0.LVDS.1:
status: connected
enabled: enabled
dpms: Off
modes: 1440x900 1440x900
edid-base64: AP/////
DRM.card0.VGA.1:
status: disconnected
enabled: disabled
dpms: Off
modes:
edid-base64:
Date: Tue Mar 29 10:07:56 2011
DistUpgraded: Log time: 2010-12-12 14:04:29.713775
DistroCodename: natty
DistroVariant: ubuntu
EcryptfsInUse: Yes
GraphicsCard:
Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:21c1]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101206)
InstallationMedia_: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101206)
InstallationMed
MachineType: LENOVO 2901CTO
ProcEnviron:
LANGUAGE=en_US:en
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
ProcVersionSign
ProcVersionSign
Renderer: Unknown
SourcePackage: unity
UpgradeStatus: Upgraded to natty on 2011-03-24 (4 days ago)
dmi.bios.date: 10/27/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6UET61WW (1.41 )
dmi.board.name: 2901CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.name: 2901CTO
dmi.product.
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.4git20110
version.libdrm2: libdrm2 2.4.23-1ubuntu5
version.
version.
version.
version.
version.
[lspci]
Nux: lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)
Related branches
CVE References
Roland Dreier (roland.dreier) wrote : | #1 |
Alex Launi (alexlauni) wrote : | #2 |
Changed in unity: | |
importance: | Undecided → Low |
status: | New → Incomplete |
Changed in unity (Ubuntu): | |
status: | New → Incomplete |
Roland Dreier (roland.dreier) wrote : | #3 |
Yes, I get similar issues when logging into a "classic" session and in fact when the system is at the gdm screen before logging in. So I reassigned to the intel driver, since this appears to be a generic X problem.
affects: | unity → xserver-xorg-video-intel |
affects: | unity (Ubuntu) → xserver-xorg-video-intel (Ubuntu) |
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Incomplete → New |
Bryce Harrington (bryce) wrote : | #4 |
Actually is most likely an issue in the kernel's drm modesetting code.
summary: |
- desktop is messed up (goes black) when laptop is docked + [arrandale] desktop is messed up (goes black) when laptop is docked |
Bryce Harrington (bryce) wrote : Re: [arrandale] desktop is messed up (goes black) when laptop is docked | #5 |
I think this is probably a dupe of bug #737891.
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | New → Incomplete |
Bryce Harrington (bryce) wrote : | #6 |
Can you try temporarily uninstalling ia32-libs and reproducing the issue, to rule out that as a possible suspect? (We had a bug on arrandale x86_64 recently that we believe was due to an old mesa in ia32-libs, but that should be fixed now.)
Roland Dreier (roland.dreier) wrote : | #7 |
OK, with ia32-libs uninstalled:
$ dpkg --list|grep ia32
rc ia32-libs 20090808ubuntu11 ia32 shared libraries for use on amd64 and ia64 systems
I get roughly the same behavior. I started with the laptop docked, and when I undocked it actually switched to the internal screen OK. Then when I redocked I got the black screen, and when undocking again I was stuck with the black screen too (only showing a pointer that still moves with the mouse).
Bryce Harrington (bryce) wrote : | #8 |
Hrm, ok at least it rules out ia32-libs.
Next thing to look at is the GPU registers. Please install xserver-
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Incomplete → New |
status: | New → Incomplete |
Hannes Beyer (hannesbeyer) wrote : | #9 |
I'm observing the same problem here. I also have a Lenovo T410s. When booting with the dock connected to a 19" monitor (1280x1024, DVI) both monitors turn black on ubuntu 11.04 beta 2 after login. LVDS1 stays black upon undocking but the mouse cursor is visible. The login screen is there, but here the resolution is not set properly.
When booting undocked and connecting the unit to its dock at a later timepoint, monitors also turn black.
Connecting a 1900x1080 TV via displayport to the notebook -without the dock- woked for me.
Things worked fine with ubuntu 10.10.
Roland Dreier (roland.dreier) wrote : | #10 |
OK, I got a chance to run intel_reg_dumper when the system is in the following states:
- docked-good.txt : in the dock with unity working properly spanning two external 1920x1080 monitors
- docked-bad.txt: in the dock with a black screen on the left monitor and the right monitor off
- undocked-good.txt: out of the dock with unity working properly on the internal 1440x900 LCD
- undocked-bad.txt: out of the dock with a black screen
Roland Dreier (roland.dreier) wrote : | #11 |
Roland Dreier (roland.dreier) wrote : | #12 |
Roland Dreier (roland.dreier) wrote : | #13 |
Roland Dreier (roland.dreier) wrote : | #14 |
correction: I said two 1920x1080 monitors but they are really 1920x1200 monitors.
summary: |
[arrandale] desktop is messed up (goes black) when laptop is docked + (x86_64) |
summary: |
- [arrandale] desktop is messed up (goes black) when laptop is docked - (x86_64) + [arrandale] desktop is messed up (goes black) when laptop is docked with + two external 1920x1200 monitors (x86_64) |
Bryce Harrington (bryce) wrote : Re: [arrandale] desktop is messed up (goes black) when laptop is docked with two external 1920x1200 monitors (x86_64) | #15 |
Roland, thanks for that.
Alright, here is what I think is happening. Arrandale graphics cards have a hardware limitation of a max texture buffer size of 4096x4096. What this means is that compositing will work only if the total screen width is 4096 or less. Over that, and the GPU can lock up or other weird things can occur.
My hypothesis is that when you are booting with the laptop docked, the internal laptop LVDS panel is disabled, so your total width is 1920+1920 which is <4096. However, when you boot with the laptop panel on and *then* dock, the kernel is adding the two monitors to the left or right of the laptop panel, resulting in 1920+1920+1440 which is >4096.
Looking at your monitors.xml, the first section shows HDMI2 and HDMI3 arranged side-by-side, and LVDS1 is also present and not disabled but not set to any particular position, so it is unclear how the kernel would position it in this case; perhaps it is adding it at +3840+0 which would fit with my hypothesis.
There are a few things you could test which might prove my hypothesis wrong:
a. This behavior should occur only with Unity/Compiz. If you boot Classic Desktop (No Effects), the system freeze should be unreproducible. (However, see below)
b. If in gnome-display-
c. If you disable your LVDS before docking (either using the GUI, or via 'xrandr --output LVDS1 --off') and then docking, the system shouldn't freeze. (I don't know if the external monitors will fire up in this case, but at least it won't trigger the freeze bug).
These may also give you some idea on working around the issue.
If those tests turn out correct, then this issue is basically a sub-case of bug #555641. However, I think that there could be some work done in gnome-display-
Now, one other caveat. It appears that there is a separate unrelated bug that is common to Arrandale, that certain RANDR operations can sometimes result in a monitor being improperly blanked. So, that may add some confusion to your testing. But the way to tell these bugs apart is that your original bug results in a system lockup (a black screen with a mouse pointer, and no way to recover), whereas with this latter blanking bug, you won't see a mouse cursor and the monitor will appear to be not getting any signal. Possibly you may be able to work around this blanking issue via this command:
xset dpms force on
Anyway, sorry for the lengthy dissertation, but hopefully with this information you can help me nail down this bug. I have some thoughts on what steps to take to get resolution to this issue (and the blanking one) but let's see if you can prove my hypothesis before we get into all that.
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Incomplete → New |
status: | New → Incomplete |
Roland Dreier (roland.dreier) wrote : | #16 |
Bruce, thanks for all the info. I will do some more testing today.
One clarification though: when I get in the black screen + mouse pointer situation, my machine is not hung. In fact the mouse pointer is still responsive, I can log in via network, etc. It just that I lose the X root background, WM stuff, etc.
Also I believe I did see similar problems with classic, although I need to double check the "no effects" part. I definitely have seen it from the GDM screen.
Roland Dreier (roland.dreier) wrote : | #17 |
Bryce, first off, sorry for mistyping your name ;)
I did a bit more testing, and I tried the classic/no effects login again. If I start undocked and dock, I do get the black screen/responsive mouse pointer. However, if I log in with classic/no effects *and* do "xrandr --output LVDS1 --off" and then dock, one monitor lights up with a real desktop (ie it seems to work). The second monitor was off, but I was able to get it to light back up by going to a text console and back to X. (I guess this is the second conflating bug you mentioned).
I tried a standard unity login and did the "xrandr --output LVDS1 --off" and I still ended up with a black but on monitor.
Bryce Harrington (bryce) wrote : | #18 |
Hi Roland, thanks for the quick response.
Regarding your clarification, yes despite how it may seem, "blank screen with moving mouse cursor and X not responding to input, but network login works" is the prototypical set of symptoms that go with a GPU hang. The kernel itself is ok, which is why you can ssh in; the mouse cursor is handled far enough outside the core of X that it is often unaffected by lockups (not always though). Often when you have a GPU lockup, there will be an error message in your 'dmesg' output. The file /sys/kernel/
Regarding the second conflating bug (which I suspect might be a DPMS bug in the kernel's arrandale code), I've a PPA you could try to see if it at least improves that situation:
Roland Dreier (roland.dreier) wrote : | #19 |
I added that ppa and updated, and did a bit more testing. It seemed to work a bit better, though not in the way I would have expected.
classic/no-effects: I started undocked, and actually got docking once to work perfectly (both monitors lit up, desktop displayed on both). However when I undocked and re-docked again, my right monitor didn't light up (although I got my desktop on the left monitor). I was not able to get the right monitor to turn on again, after trying "xset dpms force on" , the gnome monitor GUI, going to tty1 and back, etc. This situation was stable after a couple more undock/redock cycles. I never got into the black screen/moving mouse pointer situation. The kernel log never showed any intel graphics related stuff (just USB devices appearing/
unity: Again I actually got docking to work once; however the second time I docked, I got the black screen/moving mouse pointer and right monitor stuck with no signal. However neither the kernel log nor the error_state file showed anything.
Roland Dreier (roland.dreier) wrote : | #20 |
I just noticed something while looking at my Xorg.0.log after a couple of dock/undock cycles leading to the black screen. I'm attaching the full log, but what I noticed was:
boot up undocked:
[ 5.897] (II) intel(0): Allocated new frame buffer 1472x900 stride 6144, tiled
matches a 1440x900 panel
dock:
[ 370.652] (II) intel(0): Allocated new frame buffer 3840x1200 stride 15360, tiled
makes sense, I now have 2x1920x1200 monitors
undock:
[ 414.405] (II) intel(0): Allocated new frame buffer 1472x900 stride 6144, tiled
back to the 1440x900 panel
dock again:
[ 434.873] (II) intel(0): Allocated new frame buffer 1920x1200 stride 7680, tiled
now it only allocates a buffer for one monitor -- which probably explains why the second monitor never lights up
I'm not sure what layer of the stack is responsible for figuring out what buffer to allocate etc but this does seem like the first real clue I've seen to where the problem lies.
Bryce Harrington (bryce) wrote : | #21 |
Hi Roland, that's a good eye. It is the kernel modesetting portion of the stack which allocates framebuffers, and that does tend to indicate where in the core logic things may be going awry.
Since you're results with the elderberry PPA sound mixed, it's sounding to me like it would not be worth pursuing getting that change into natty. Do you agree, or do you see some value to it?
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Incomplete → Confirmed |
Roland Dreier (roland.dreier) wrote : | #22 |
I don't think the elderberry stuff is related to my issue -- I see a monitor stuck with no signal because (if I understood correctly) KMS got confused and forgot about it. Probably fixing KMS would fix my problems.
Is there some i915 tracing I could turn on to figure out what is confusing the kernel driver?
I guess I'll try a 2.6.39-rc upstream kernel to see if that makes any difference.
Bryce Harrington (bryce) wrote : Re: [Bug 745112] Re: [arrandale] desktop is messed up (goes black) when laptop is docked with two external 1920x1200 monitors (x86_64) | #23 |
On Thu, Apr 21, 2011 at 12:27:20AM -0000, Roland Dreier wrote:
> I don't think the elderberry stuff is related to my issue -- I see a
> monitor stuck with no signal because (if I understood correctly) KMS got
> confused and forgot about it. Probably fixing KMS would fix my
> problems.
>
> Is there some i915 tracing I could turn on to figure out what is confusing the kernel driver?
> I guess I'll try a 2.6.39-rc upstream kernel to see if that makes any difference.
Yes, the xdiagnose utility allows switching on drm debug messages (the
first checkbox). You might also experiment with disabling vesafb but
I'm doubtful that would do anything in this case.
In addition to testing the .39-rc kernel, you can test Intel's
experimental tree which we package for Ubuntu now for testers:
http://
Changed in xserver-xorg-video-intel (Ubuntu): | |
importance: | Undecided → Medium |
Roland Dreier (roland.dreier) wrote : Re: [arrandale] desktop is messed up (goes black) when laptop is docked with two external 1920x1200 monitors (x86_64) | #24 |
With linux-image-
I captured some kernel logs, and when I get a chance I'll do the same for the stock natty kernel so we can compare.
Bryce Harrington (bryce) wrote : | #25 |
I have duped bugs #750259, #734756, and #747205 here.
Bug #737891 also exhibits this same issue but also conflates it with another issue where creating a screen >4096 wide exceeds the max texture width (as per the linked upstream bug), so I'm going to let that bug focus on that particular issue (which really is more of a gnome configuration tool issue).
Bryce Harrington (bryce) wrote : | #26 |
On lp #747205 we discovered by creating a new user account, that having certain RANDR operations present in monitors.xml would trigger it, presumably because gnome-settings-
734756 collected register dumps on the issue, and experimented with some dpms forcing from the userspace side. My elderberry PPA was found to have some positive effects, but didn't fix it sufficiently completely to warrant pursuing that to work around the kernel issue. drm-intel-
Video and photos are available on bug #750259. We also examined gpu error states and found this bug is not a gpu lockup issue (as 747205 suggested). The drm-intel-
Bug #737891 includes reports of this issue, among other problems. Maverick was re-tested via livecd and the issue was not reproduced (maybe for the same reasons as creating a new account in bug 747205 did not reproduce? Reporters also found that deleting monitors.xml has an ameliorative effect.) Fiddling with which monitor was listed as primary in monitors.xml appeared also to resolve things for at least one person.
Bryce Harrington (bryce) wrote : | #27 |
Bug #761236 is the broken-out portion of bug #737891 which is this specific issue. On that report, it was found that kernel 2.6.39-0.4~20110419 resolved it, but the elderberry PPA with the -intel workaround did not.
Changed in linux (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Critical |
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Confirmed → Triaged |
status: | Triaged → In Progress |
Bryce Harrington (bryce) wrote : | #28 |
That should capture all the background on the various instances of this bug that I've been working with people on. Basically, there are some variations in symptoms but all of the reports are particular to Arrandale, occur in relationship with setting up external screens (perhaps something relating to primary monitor settings), and appear to be fixed in the latest kernel.
The next step for this bug is that we need to narrow down what patch in the upstream kernel provides the fix. The best way to achieve this is via doing a git bisection search. Unfortunately none of us Ubuntu-X guys have Arrandale hardware, so if this bug is going to get fixed in natty we need a volunteer to do this. It is a bit technical but well documented in a paint-by-numbers fashion at https:/
Bryce Harrington (bryce) wrote : | #29 |
An alternative thing to investigate: There is another bug particular to Sandybridge, with roughly similar symptoms to this one, which has already been git bisected and found a candidate patch. The flagged patch with the fix appears to also affect Arrandale, so I have a hunch it *might* also solve this bug. But that's just a wild guess. Please install and boot this kernel to see if the issue can be reproduced; if not, then this bug may be a dupe of bug #761065:
Greg Wilkins (gregw-wiltel) wrote : | #30 |
I was having a very similar issue with a thinkpad X201 (see https:/
However, booting with the monitors plugged in made no difference - I would go to the black screen regardless when I logged in an existing account.
However, a freshly created account was able to display two monitors and worked OK with monitor connects and disconnects.
I removed all the compiz files from the existing account and then logged in with a classic no affects session. This gave me black screens, but I was able to hit fn-f7 and my screens cycled through various combinations. Some of these were all black, but some worked, including both screens full resolution (not mirrored) and just external monitor.
I was then able to log out and back in with a classic with effects session, and this now works! However, if I fn-f7 too much, then eventually I end up in the black screens with only X cursor situation and have to restart X to get out of it.
description: | updated |
Unkraut (unkraut2) wrote : | #31 |
Dear Bruce!
I tried your kernel and experienced exactly the same problems as with the stock ubuntu kernel.
Could anyone please confirm this?
Unkraut (unkraut2) wrote : | #32 |
Switch back to kernel 2.6.35-28 from maverick solved most issues for me. I can recomend this as a workaround.
Hannes Beyer (hannesbeyer) wrote : | #33 |
I installed kernel 2.6.36-
Ed Swierk (eswierk) wrote : | #34 |
I installed kernel 2.6.39-
Sebastián García Rojas (sebagr) wrote : | #35 |
I've just installed linux-headers-
Peter L. Hansen (peter-r12) wrote : | #36 |
I installed kernel 2.6.39 and it too fixed the problem on my ThinkPad T410 such i can use it with my docks again, with different configurations.
But the machine has been significantly slower and it has introduced crashes. Is this because of the PPA software? Debug mode or something the like?
Martin Pool (mbp) wrote : | #37 |
Is it worth updating the title to clarify this bug also apparently covers cases where just a single monitor doesn't work (as some of the bugs duped to this complain.)
tags: | added: oneiric |
Bryce Harrington (bryce) wrote : | #38 |
[I've marked this bug for inclusion in our oneiric bug queue. While technically this bug has not been re-confirmed against oneiric, I feel it is worth continued development attention. We will need to ask that it be re-confirmed once oneiric is further along, perhaps once we get closer to alpha.]
Ruairi (ruhann) wrote : | #39 |
I installed 2.6.29 from the PPA, this fixed the problem in ubuntu classic. In the unity desktop with 2.6.39 I can have choose one monitor only, with two monitors I have issues where the workspace is not the same size as the screen.
Yoni Tsafir (yonix85+launchpad) wrote : | #40 |
Had a similar bug on my ThinkPad x201.
Installing 2.6.39 kernel as suggested solved the frequent crashes, but certain areas of the screen still remained unusable.
Finally, the workaround I found for this was to delete ~/.config/
Changed in xserver-xorg-video-intel (Ubuntu): | |
assignee: | nobody → Timo Aaltonen (tjaalton) |
Changed in linux (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in linux (Ubuntu Natty): | |
importance: | Undecided → High |
status: | New → Fix Committed |
Changed in xserver-xorg-video-intel (Ubuntu): | |
assignee: | Timo Aaltonen (tjaalton) → nobody |
status: | Fix Released → Invalid |
Changed in linux (Ubuntu Natty): | |
assignee: | nobody → Timo Aaltonen (tjaalton) |
Changed in xserver-xorg-video-intel (Ubuntu Natty): | |
status: | New → Invalid |
summary: |
- [arrandale] desktop is messed up (goes black) when laptop is docked with - two external 1920x1200 monitors (x86_64) + [arrandale] desktop is messed up with external monitors (x86_64) |
Changed in linux (Ubuntu Natty): | |
status: | Fix Committed → Fix Released |
Changed in linux (Ubuntu): | |
status: | Fix Released → Triaged |
Changed in linux (Ubuntu Natty): | |
status: | Fix Released → Triaged |
tags: | added: regression-update |
Changed in xserver-xorg-video-intel: | |
importance: | Low → Unknown |
status: | Incomplete → Unknown |
Changed in linux (Ubuntu Precise): | |
assignee: | nobody → Timo Aaltonen (tjaalton) |
importance: | Critical → High |
Changed in xserver-xorg-video-intel: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
|
#129 |
> xrandr --output DP1 --set audio off
looks good:
I plugged my laptop into the dock, and it came up at the medium
resolution it was running at earlier in the day. I ran that command,
and the screen blanked briefly, I guess while the dp link was
reestablished. I then used the displays panel to switch up to full
resolution and it worked.
So, 1/1. But, this has always been a bit intermittent, so more
testing might be needed.
|
#130 |
Hitting Fn-F7 a few more times, I still have the blank screen problem,
and turning dp audio off again does not fix it.
|
#134 |
I've tried, as a bit of a shot in the dark, cutting out one bit of code that seems to try to enable the audio pipe, and this does not seem to be enough to make it reliable when the display is configured automatically.
diff --git a/drivers/
index db3b461..007c68b 100644
--- a/drivers/
+++ b/drivers/
@@ -867,10 +867,14 @@ intel_dp_
}
if (intel_
- DRM_DEBUG_
- pipe_name(
- intel_dp->DP |= DP_AUDIO_
- intel_write_
+ if (1) {
+ DRM_DEBUG_
+ } else {
+ DRM_DEBUG_
+ pipe_name(
+ intel_dp->DP |= DP_AUDIO_
+ intel_write_
+ }
}
|
#131 |
I tried the current tip of drm-intel-
|
#132 |
It seems like if I force audio off at the same time I add the external screen, through xrandr, it does work reliably(?) so far. Using the monitor control panel or fn-f7 apparently puts audio back to the 'auto' setting, which does induce a problem
I tried running
for i in `seq 30` ;do; echo i && xrandr --output DP1 --off && sleep 15 && xrandr --output DP1 --mode 2560x1600 --above LVDS1 --set audio off && sleep 15 || break;done
and this got through 14 iterations successfully.
Now I wonder if I can identify what the problem is with audio or provide a way to force it off. This screen does have an option for speakers to be connected, but I'm not using it. I don't know if it picks up audio across dp.
|
#133 |
Running
xrandr --output DP1 --mode 2560x1600 --above LVDS1 --set audio on
when it's previously working does immediately make the monitor black out, and using '--set audio off' does not bring it back, nor does soft power cycling the monitor or unplugging/
I can see some reports of people complaining about dp/audio problems under windows with the U3011, but it's hard to tell how much they indicate a real hardware/firmware problem vs windows driver problems or something else.
http://
> It seems that the Nvidia based implementation at least with Displayport "++" out will only support an audio signal being passed over displayport to an external monitor that is no high resolution than 1080HD, or 1920x1080.
So I wonder if there is some way for Linux to know not to try this, preferably without needing special user configuration:
* don't do audio above a certain resolution?
* ... on specific hardware models?
* don't do DP audio at all by default?
|
#135 |
I tried a couple of variations on that patch to try to force dp audio off, with no success. If someone gives me a patch or an idea on where to start I'm happy to try it.
|
#136 |
Just to be clear: forcing audio off every time the external display is configured, by using "xrandr ... --set audio off", does make it work reliably every time so far.
What I tested previously, and what did not work to turn it off just once and then use the system's normal configuration method (eg fn-f7), I guess because that is effectively configuring the monitor with auto audio.
So it does seem that the problem is related to audio; in my particular situation being able to force it off all the time would at least hide the problem. I don't care about sending audio to my monitor, but I suppose others do, so a patch that just turns it off across the board probably wouldn't be accepted.
I guess the next thing to work out is:
* audio actually can't work on this channel with this resolution (not enough bandwidth?)
* there's a bug in this monitor to do with audio at high resolution?
* there's some other bug in the kernel about dp audio?
* ...?
|
#144 |
The problem i describe in <https:/
Leaving that aside, with the one patch from <https:/
|
#145 |
Now that I know not to use recovery mode (which might be a separate less important bug), <http://
|
#146 |
And <https:/
|
#137 |
the current tip of drm-intel-fixes does seem to have this fixed (but drm-intel-
|
#138 |
so perhaps the fix for https:/
c898261c0dad617
will also fix this...
|
#139 |
Ogasawara's build http://
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1600 x 1200, maximum 1600 x 1200
default connected 1600x1200+0+0 0mm x 0mm
1600x1200 0.0*
1280x1024 0.0
1024x768 0.0
800x600 0.0
640x480 0.0
Martin Pool (mbp) wrote : | #140 |
http://
does seem to work correctly.
I'm going to try what I think is the right patch applied to the precise kernel.
Martin Pool (mbp) wrote : | #141 |
I built Ubuntu-3.2.0-15.24
from git://kernel.
https:/
and that does seem to fix the problem, hooray. Maybe that one fix can be cherrypicked into the Ubuntu kernel?
The binary is in http://
(I think the wonky version number is just due to mixing make-kpkg and a debian-style tree?)
I'm going to see if it will work on Oneiric too, and perhaps also do a clean build of it.
Martin Pool (mbp) wrote : | #142 |
Here's an attempted backport of that patch to the oneiric kernel; not tested yet.
tags: | added: patch |
Martin Pool (mbp) wrote : | #143 |
on precise, <http://
on oneiric's kernel, <https:/
If drm-intel-fixes works flawless, but just backporting the patch does not yet work so great, we likely miss a few of the recent dp fixes in -stable trees.
Closing this, please reopen if it shows up again or file a new bug reporter if you still have other issues left.
Changed in xserver-xorg-video-intel: | |
status: | Confirmed → Fix Released |
Leann Ogasawara (leannogasawara) wrote : | #148 |
Hi Martin,
Thanks for all the extra testing and feedback. I'd been looking at bug 912387 (fdo bug 44881) in parallel. The patch to fix bug 912387 appears to provide a fix for the issue you are seeing here. I've therefore cherry-pick'ed the patch in question from the drm-intel-fixes branch into Precise prior to the patch officially hitting the mainline kernel. So this issue should be resolved in Precise after the next upload (which I intend to do before the end of the week).
I see that the patch has also been CC'd to upstream stable. Once the patch does land in mainline, it'll then propagate through to the upstream stable releases. This means that it should land in Oneiric automatically through our normal SRU process and not require any further action on our part. Thanks.
Changed in linux (Ubuntu Precise): | |
status: | Triaged → Fix Committed |
Launchpad Janitor (janitor) wrote : | #149 |
This bug was fixed in the package linux - 3.2.0-16.25
---------------
linux (3.2.0-16.25) precise; urgency=low
[ Andy Whitcroft ]
* d-i -- include the Hyper-V drivers in the virtio udeb
- LP: #917135
[ Felix Fietkau ]
* (pre-stable): ath9k_hw: fix a RTS/CTS timeout regression
- LP: #925602
[ Keith Packard ]
* SAUCE: drm/i915: Force explicit bpp selection for
intel_
- LP: #745112, #912387, #917330
[ Leann Ogasawara ]
* Fix typo in generic-pae description
- LP: #928448
* Rebase to v3.2.6
[ Upstream Kernel Changes ]
* procfs: parse mount options
- CVE-2011-4917
* procfs: add hidepid= and gid= mount options
- CVE-2011-4917
* proc: fix null pointer deref in proc_pid_
- CVE-2011-4917
* xhci: Remove warnings about MSI and MSI-X capabilities.
- LP: #929656
* xhci: Remove scary warnings about transfer issues.
- LP: #929656
* x86, mce, therm_throt: Don't report power limit and package level
thermal throttle events in mcelog
- LP: #930288
* rebase to v3.2.6
- LP: #924320
- LP: #918254
-- Leann Ogasawara <email address hidden> Mon, 13 Feb 2012 13:00:08 -0800
Changed in linux (Ubuntu Precise): | |
status: | Fix Committed → Fix Released |
Martin Pool (mbp) wrote : | #150 |
Thanks, Leann.
I have just tried 3.2.0-16.25 and it's not completely working, the external monitor is still black at high resolutions. I'll investigate some more.
Martin Pool (mbp) wrote : | #151 |
One apparently regression in 3.2.0-16.25 (maybe unconnected to this change?) is that fn-f7 does not seem to have any effect. It was working on the previous kernel I tried, both the Ubuntu ones and my own builds.
Turning on the external screen with xrandr does work:
xrandr --output DP1 --mode 2560x1600 --set audio off --above LVDS1
Using the displays control panel, the first time I tried, the monitor showed an error about the signal being wrong. I've just tried again and it has worked. So, I'm not sure. Also, after using the monitors control panel, Fn-F7 is working again. (So, perhaps the bug is in userspace?) I'll see if I can get a better description of what the problem is.
Martin Pool (mbp) wrote : | #152 |
Martin Pool (mbp) wrote : | #153 |
This is definitely improved but not fixed. Most of the time the external monitor comes up ok, but sometimes when I switch a running session on to the external monitor it stays irretrievably blank. Here's a kernel log with debugging on of those transitions.
I have not yet worked out the pattern or a reliable reproduction.
Martin Pool (mbp) wrote : | #154 |
Current status in Precise seems to be:
- works reliably with ` xrandr --output DP1 --mode 2560x1600 --set audio off`
- fairly reliably **does not** work if I set the external monitor direct to 2560x1600 from the monitors control panel, I'm guessing because that does auto audio and gets it wrong.
Changed in linux (Ubuntu Precise): | |
status: | Fix Released → Triaged |
|
#155 |
Using the current kernel from Precise, which is supposed to have the latest patches, my external monitor works if audio is forced off using xrandr, but fails if audio is left in auto mode. So, reopening.
Changed in xserver-xorg-video-intel: | |
status: | Fix Released → Confirmed |
On Sat, 10 Mar 2012, Martin Pool wrote:
> Using the current kernel from Precise, which is supposed to have the
> latest patches, my external monitor works if audio is forced off using
> xrandr, but fails if audio is left in auto mode. So, reopening.
please follow up on the upstream bug as well
Martin Pool (mbp) wrote : | #157 |
That comment was on the upstream bug, Launchpad just forwarded it to you ;)
tags: | added: precise rls-mgr-p-tracking |
|
#158 |
On Ubuntu's current kernel (3.2.0-20-generic #32-Ubuntu SMP Thu Mar 22 02:22:46 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux), the behaviour is:
* after booting, the machine comes up ok to the lightdm screen, and after logging in it restores the previous configuration correctly, ie external monitor at full resolution and internal screen off
* if I log out, both screens go black and stay black
tags: | added: kt-worked |
Two things may be going on here:
1) we're setting the DP audio enable bit too early I think; we should only set it when we go to a normal link mode
2) there may not be enough bw for audio at 25x16 with the clock configuration we use, we may need to reduce the audio config somehow
Paulo, do you have a DP monitor you can test with to confirm?
I just confirmed that 25x16 works fine on my ILK laptop with drm-intel-
Martin, it would be good if you could re-test with drm-intel-
Changed in xserver-xorg-video-intel: | |
status: | Confirmed → Incomplete |
Timo Aaltonen (tjaalton) wrote : | #160 |
Martin: here's a kernel build with that branch:
http://
(d-i-e mapped to d-i-n-q)
Is this still an issue on 3.6-rc kernels?
Timo Aaltonen (tjaalton) wrote : | #162 |
Please test with 3.6-rc kernel from http://
no longer affects: | linux (Ubuntu Natty) |
Changed in linux (Ubuntu): | |
status: | Triaged → Incomplete |
|
#163 |
Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks.
|
#164 |
I have tried this screen and machine with 3.6 and so far it seems to be
working.
Martin
On Oct 22, 2012 1:30 AM, <email address hidden> wrote:
> Chris Wilson <email address hidden> changed bug 45211<https:/
> What Removed Added Status NEEDINFO RESOLVED Resolution --- INVALID
>
> *Comment # 24 <https:/
> 45211 <https:/
> Wilson <email address hidden> *
>
> Timeout. Please do reopen if you can still reproduce the issue and help us
> diagnose the problem, thanks.
>
> -------
> You are receiving this mail because:
>
> - You reported the bug.
>
>
Marking as fixed then, pls reopen if it blows up again, and thanks for submitting the status update.
Changed in xserver-xorg-video-intel: | |
status: | Incomplete → Fix Released |
psny18 (psny18) wrote : | #166 |
I'm not sure if I'm in the right place, but on my T61 + docking station I have an issue with desktop files/folders not being displayed correctly. With either VGA or DVI, everything works great but the files/folders in the Desktop/ folder are not constrained to the viewable area. They remain on the laptop monitor (can be dragged to the external monitor) but they are off the screen. "Organize Desktop by Name" has the same result.
So, it seems that the area allocated to icons is bigger than the actual display.
psny18 (psny18) wrote : | #167 |
sorry, forgot my details
12.04 LTS x86_64 with 3.2.0-34-generic
Timo Aaltonen (tjaalton) wrote : | #168 |
closing as wontfix for precise, it'll get in a point release anyway and the fixing commit is very hard to identify
Changed in linux (Ubuntu Precise): | |
status: | Triaged → Won't Fix |
Changed in linux (Ubuntu): | |
status: | Incomplete → Fix Released |
The issue you're describing doesn't sound related to Unity. Could you log into a Gnome 2 session and see if this issue persists?