Lenovo T440s freezes when connected to docking station

HW: Lenovo T440s with a Thinkpad Ultra Dock and a Dell U2410

The T440s was at the docking station when powering on.

If I start the X-server, plugin the Monitor to a DP connector at the docking station and call `xrandr --output DP2 --preferred` the X-server freezes. (Doesn't happen without the docking station at the mDP connector directly at the notebook.)

By freeze I mean:
- no cursor movement
- no VT switching

Though the maschine is reachable via ssh:
- X-server ignores `kill -9`

After 2 minutes the following kernel message shows up:
[ 480.195776] INFO: task kworker/0:1:34 blocked for more than 120 seconds.
[ 480.195779] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 480.195781] kworker/0:1 D 0000000000000246 0 34 2 0x00000000
[ 480.195803] Workqueue: events ironlake_panel_vdd_work [i915]
[ 480.195805] ffff880118cebd50 0000000000000046 0000000000014500 ffff880118cebfd8
[ 480.195809] ffff880118cebfd8 0000000000014500 ffff880119218870 ffff88011f214570
[ 480.195812] 0000000000000001 ffff880118cebcd8 ffffffff8109a884 ffff88011f2d4500
[ 480.195816] Call Trace:
[ 480.195822] [<ffffffff8109a884>] ? dequeue_entity+0x144/0x4d0
[ 480.195825] [<ffffffff81099815>] ? set_next_entity+0x95/0xb0
[ 480.195829] [<ffffffff810135a8>] ? __switch_to+0x118/0x4e0
[ 480.195833] [<ffffffff814e1029>] schedule+0x29/0x70
[ 480.195835] [<ffffffff814e1463>] schedule_preempt_disabled+0x23/0x30
[ 480.195839] [<ffffffff814df9d8>] __mutex_lock_slowpath+0x168/0x3b0
[ 480.195843] [<ffffffff814dfc32>] mutex_lock+0x12/0x30
[ 480.195852] [<ffffffffa060a8b5>] ironlake_panel_vdd_work+0x25/0x40 [i915]
[ 480.195855] [<ffffffff8107c6e7>] process_one_work+0x167/0x450
[ 480.195858] [<ffffffff8107d0f1>] worker_thread+0x121/0x3a0
[ 480.195861] [<ffffffff8107cfd0>] ? manage_workers.isra.23+0x2b0/0x2b0
[ 480.195865] [<ffffffff81083960>] kthread+0xc0/0xd0
[ 480.195868] [<ffffffff810838a0>] ? kthread_create_on_node+0x120/0x120
[ 480.195871] [<ffffffff814ea52c>] ret_from_fork+0x7c/0xb0
[ 480.195875] [<ffffffff810838a0>] ? kthread_create_on_node+0x120/0x120

The bug occured with
  o kernel 3.10.12
  o xorg 1.14.3
  o xf86-video-intel 2.11.15

For this test and the following logs it has been reproduced with
  o kernel 3.11.6
  o xorg 1.14.4
  o xf86-video-intel (at git head - dc61705 sna: Use an inplace exchange for large untiled BO).

A test with kernel 3.12 is in the queue.

Created attachment 88694
dmesg 3.11.6 (drm.debug=0x7)

Created attachment 88695
Xorg.0.log (intel git:dc61705, --enable-debug=full)

Can you please boot with drm.debug=0xe added to your kernel cmdline, reproduce the issue (up to the stuck task backtrace) and then grab the complete dmesg? Also retesting on 3.12 might be worth a shot.

Created attachment 88700
dmesg 3.11.6 (drm.debug=0xe)

(In reply to comment #3)
> Can you please boot with drm.debug=0xe added to your kernel cmdline,
> reproduce the issue (up to the stuck task backtrace) and then grab the
> complete dmesg?

Done.

> Also retesting on 3.12 might be worth a shot.

Still takes some time. But, will be done.

(In reply to comment #4)
> Created attachment 88700 [details]
> dmesg 3.11.6 (drm.debug=0xe)

There seems to be nothing terrible going wrong leading up to the backtrace. So looks like a new kind of bug. Can you please recompile with lockdep (CONFIG_PROVE_LOCKING) enabled and regrab a drm.debug dmesg of the hang? That should list all the other task hogging the mutex and hopefully shed more light onto what's going wrong here.

Created attachment 88748
dmesg 3.12.0 (drm.debug=0xe)

(In reply to comment #7)
> Created attachment 88748 [details]
> dmesg 3.12.0 (drm.debug=0xe)

Anything else I can/should provide?

Just rushed through some tests:
- I've tested all the other connectors (HDMI, DVI and VGA) at the docking station with the same technique (boot with notebook in docking station, external monitor not plugged in, start X, connect monitor, enable output via xrandr):
  o The xrandr output was always DP2.
  o All had the same problem, the hung timer showed up for ironlake_panel_vdd_work.

- Additionally, I've tried to boot with the monitor already connected. Here the maschine gets stuck in a very early state (No output on the monitor nor LVDS - well eDP) where the network is not up. So I can't grab any logs here.

Ah, we maybe corrupting the panel_vdd_work item. Try

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf961698f847..6ac2303f33db 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1161,9 +1161,14 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
                return;

        WARN(!intel_dp->want_panel_vdd, "eDP VDD not forced on");
-
        intel_dp->want_panel_vdd = false;

+ if (cancel_delayed_work(&intel_dp->panel_vdd_work)) {
+ mutex_unlock(&dev->mode_config.mutex);
+ cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
+ mutex_lock(&dev->mode_config.mutex);
+ }
+
        if (sync) {
                ironlake_panel_vdd_off_sync(intel_dp);
        } else {

And now compiles:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf961698f847..8c2b744b03a3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1161,9 +1161,16 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
                return;

        WARN(!intel_dp->want_panel_vdd, "eDP VDD not forced on");
-
        intel_dp->want_panel_vdd = false;

+ if (cancel_delayed_work(&intel_dp->panel_vdd_work)) {
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+
+ mutex_unlock(&dev->mode_config.mutex);
+ cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
+ mutex_lock(&dev->mode_config.mutex);
+ }
+
        if (sync) {
                ironlake_panel_vdd_off_sync(intel_dp);
        } else {

Dropping just the config.mutex is dangerous, especially when we also call this function from the disable/enable hooks where we always also hold the relevant crtc->mutex.

I wonder a bit though who's hogging the kms lock - we chase an awful lot of pointers to get at it, so if someone's corrupting this I expect we'd blow up. And lockdep shouldn't be too happy about it either. Confusing.

(In reply to comment #12)
> I wonder a bit though who's hogging the kms lock - we chase an awful lot of
> pointers to get at it, so if someone's corrupting this I expect we'd blow
> up. And lockdep shouldn't be too happy about it either. Confusing.

My theory is that the work item is being called twice. Crazy, huh? But since we seem to be very cavalier in scheduling the work even if it is already queued, I think it is reasonable to assume that we shoot ourselves in the foot.

On Sat, Nov 9, 2013 at 12:17 PM, <email address hidden> wrote:
> --- Comment #13 from Chris Wilson <email address hidden> ---
> (In reply to comment #12)
>> I wonder a bit though who's hogging the kms lock - we chase an awful lot of
>> pointers to get at it, so if someone's corrupting this I expect we'd blow
>> up. And lockdep shouldn't be too happy about it either. Confusing.
>
> My theory is that the work item is being called twice. Crazy, huh? But since we
> seem to be very cavalier in scheduling the work even if it is already queued, I
> think it is reasonable to assume that we shoot ourselves in the foot.

The work item should check whether it's run already (or whether we
killed the vdd synchronously), so double-scheduling shouldn't be
harmful. If that isn't, we have a big bug.

(Sorry, I've been stuck at meetings this week and so will I during the rest of the week.)

(In reply to comment #11)
Just had time for a quick boot test with the patch. As soon as i915 loads it raises a kernel panic "unbalanced lock". I'll grab the log later.

Created attachment 89187
dmesg, v3.12.0 + Patch from comment #11 - BUG: bad unlock balance detected!

Created attachment 89905
dmesg 3.12.0-rc1 (WITHOUT DOCK! - monitor directly at laptop)

dmesg wo/ docking station as reference

(In reply to comment #17)
> Created attachment 89905 [details]
> dmesg 3.12.0-rc1 (WITHOUT DOCK! - monitor directly at laptop)

Ups, 3.13.0-rc1.

Created attachment 89906
dmesg 3.13.0-rc1

dmesg w/ docking station

(In reply to comment #133)
> (In reply to comment #132)
> > I have got the following devices:
> > * T440s (Kernel 3.13.2)
> > * Dock (fw2.10)
> > * Dock (fw2.17)
> >
> > If I can provide additional logs, please give me infos on which scenarios
> > (/patches).
>
> Apply the patches from this thread:
> http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/33737 to
> linux-3.13.2 and provide dmesg output with 'drm.debug=0xe' kernel parameter.

For convenience, rebased on top of v3.13.2:
http://cgit.freedesktop.org/~jani/drm/log/?h=native-aux-defer-v3.13.2

Jani, for the record, I did my tests with your two patches before I updated the dock firmware, and it definitely did make the hangs go away --- and as I mentioned, I was even able to connect to an external Dell LCD panel using DP without any problems (although the "too many retries" debug message did trigger).

Many thanks for working on this issue, and I agree that the kernel should not be hanging even if the dock is buggy. I have two Ultradocks (one at work and one at home) --- would it be helpful if I keep one unupgraded for now? From looking at the intel-gfx list it sounds like you are planning on changing the infrastructure to use some new infrastructure in the next kernel version or two? If you'd like me to do some testing of the new code with a buggy dock, I'm happy to keep one of my docks at the old firmware version, especially since the two patches seem to be an adequate workaround.

(In reply to comment #135)
> Many thanks for working on this issue, and I agree that the kernel should
> not be hanging even if the dock is buggy. I have two Ultradocks (one at
> work and one at home) --- would it be helpful if I keep one unupgraded for

Me too.
I can help as well.

> now? From looking at the intel-gfx list it sounds like you are planning on
> changing the infrastructure to use some new infrastructure in the next
> kernel version or two? If you'd like me to do some testing of the new code
> with a buggy dock, I'm happy to keep one of my docks at the old firmware
> version, especially since the two patches seem to be an adequate workaround.

(In reply to comment #124)
> (In reply to comment #122)
> > I also get a mirrored output on VGA, however I could not extend to that
> > adapter. (it seems to be a hardware mirror, I only see one external display,
> > DP2, in XrandR...)
>
> Same here. Switching to one external DP display now works like a charm. Gets
> identified as DP2 in xrandr.
>
> Connecting a second DP display result in a mirrored output. Both external
> displays are identified as DP2.
>
> There seems to be still a problem enumerating the devices connected to the
> DP hub

Same on a Thinkpad W540 with Ultra Dock. Ubuntu 13.10 3.14.0-031400rc1-generic

I have a W540 that also freezes when trying to use DP, with the difference that I don't see any oops or error message in neither the kernel logs, nor the X logs. When I plug in an external monitor, xranrd shows it as connected to DP2, regardless of whether it's connected to DP1, DP2, DVI or HDMI. On one occasion, I have been able to get a mirror output on both DP1 and DP2 (still after 1-2 min of freezing), even though xrandr still showed only DP2 as being connected. I have been unable to reproduce that partial success since. During the freeze, Xorg keeps using a steady 20% CPU, but any attempt at attaching gdb to the Xorg process only resulted in gdb feezing (had to kill -9 it). Anything I can run to help debugging this?

(In reply to comment #138)
> When I plug in an external monitor, xranrd shows it as connected
> to DP2, regardless of whether it's connected to DP1, DP2, DVI or HDMI.

From how I understand it, this is because all the display connectors are provided through a DP MST hub that is working in the dock. This hub then provides three possible outputs (VGA, digital group 1 and digital group 2). We need DP MST support.

It looks like MST is required to drive 4k monitors

read here: http://askubuntu.com/questions/369946/displayport-1-2-mst-daisy-chain-dual-monitor-setup-intel-graphics

If this is true i think it will be implemented soon. Does anybody know if there is still work for MSt support? i can't find anything about it.

Is MST actually required for 4K / 60Hz monitors, or is HBR2 / DP 1.2 sufficient? (My understanding is that Intel Linux drivers already support HBR2)

I don't know. So without MST support there will be no way to connect more than one monitor to the dock?

Created attachment 93971
dmesg-jani-patches-docked.txt

dmesg output from drm module with changes proposed by Jani while the computer was booted while docked.

Created attachment 93972
dmesg-jani-patches-undocked.txt

dmesg output from drm module with changes proposed by Jani while the computer was booted while undocked. The computer is then docked and the display spilt using xrandr.

(In reply to comment #131)
> From the kernel perspective it's fixed when we don't freeze the machine even
> when a dock with buggy firmware is connected, which is what my patches fix.
>
> Plus we need to follow-up on comment #125.

Jani, my earlier comment was a false alarm. My apologies. I confirm that your patches work very well for my T440s with an Ultra Dock (firmware not updated). I tested with following two scenarios:
1. Booting while docked and then using xrandr to split the display.
2. Booting undocked and then dock and use xrandr to split the display.
The changes worked well for both scenarios, albeit some minor delay which is very much acceptable.

As mentioned by Tso earlier, there were some "*ERROR* too many retries, giving up" messages. Here are the dmesg outputs for the above two scenarios.
https://bugs.freedesktop.org/attachment.cgi?id=93971
https://bugs.freedesktop.org/attachment.cgi?id=93972

This bug may now be closed.

Thanks!

Thanks everyone for reporting this and testing patches, fix is now on track for 3.14 and stable kernels:

commit 2f589112609b0a964b3d78c99c0f3a83ac16add6
Author: Jani Nikula <email address hidden>
Date: Tue Feb 11 11:52:05 2014 +0200

    drm/i915/dp: add native aux defer retry limit

Created attachment 94007
dmesg with patch applied, old firmware

I applied the patch on the FC20 3.12 kernel and although there was no freeze, I got some scary error messages in my kernel logs. See attached output. This is a Lenovo W540 laptop running Fedora 20 with the latest laptop BIOS, but the old dock firmware.

(In reply to comment #147)
> Created attachment 94007 [details]
> dmesg with patch applied, old firmware
>
> I applied the patch on the FC20 3.12 kernel and although there was no
> freeze, I got some scary error messages in my kernel logs. See attached
> output. This is a Lenovo W540 laptop running Fedora 20 with the latest
> laptop BIOS, but the old dock firmware.

That is to be expected if the display port sink replies with repeated aux defer messages. Error for the retry limit first, then error for the modeset failing due to this. Don't worry about it.

(The modeset failure message comes from the post-modeset state checker. We could handle this more gracefully, but there are scenarios where the failures we detect during modeset do not result in a non-working display... while bailing out early would definitely result in a non-working display.)

(In reply to comment #85)
> I care about getting this fixed, so I'm offering USD 100.00 via
> FreedomSponsors to the first person who fix it.
>
> Offer link:
> http://www.freedomsponsors.org/core/issue/433/sna-haswell-x-server-freezes-
> when-enabling-dp-at-docking-station
>
> You can also join me and throw in a few bucks there and we'll get it fixed
> faster :)
>
> If you fix this issue (see my acceptance criteria there) please use that
> site to request your payment.

We had a bug in the driver, and thanks to this bug report it's now fixed. Everyone, thanks for the report and testing! I hear a firmware upgrade in the dock also fixes the issue, but it doesn't mean we didn't have a bug.

As the fix ended up being my commit, I feel I should express my view on the offered bounty. This is speaking solely for myself, not for my employer or colleagues. Regardless of the firmware fix, I think it would be unethical of me to accept any part of the bounty.

I am employed to work on the driver, and fixing issues like this is part of the job. Personal prize money should not directly affect, or give an impression that it would affect, the priorities I set and am given as an employed developer. This is also a team effort. I contributed the fix, but many developers were involved in the triage, and people who tested the patches likely spent more time on this than I did! (Thanks again!)

All that said, I appreciate the offer and FreedomSponsors in general, and I would have no qualms about accepting bounties for things I work on in a hobbyist capacity.

If you still feel indebted for having made the offer, please consider sponsoring some other task or donating to a charity of your choosing.

Thanks.

Jani,

Well spoken, respect.

That is why I love Open Source!
It tends to attract people with the 'right kind' of attitude AFAIC.

So thanks to everyone involved!

Keep up the good work :-)

Hi Jani

Awesome attitude, thanks for fixing this.

Do you know when there is an official new driver including this fix available on https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=13815 or similar site (I for some reason cannot connect to the site right now, but I think it's where I got my last Intel linux driver).

Thanks in advance!

(In reply to comment #151)
> Do you know when there is an official new driver including this fix
> available on https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=13815
> or similar site (I for some reason cannot connect to the site right now, but
> I think it's where I got my last Intel linux driver).

CC Rodrigo, I think this question is for you. ;) The fix itself is queued to 3.14 and -stable.

Dual display is confirmed working after firmware upgrade.

I'm dual booting Arch Linux (uname -r: kernel 3.12.9-2-ARCH) and Windows 7 on a Thinkpad T440 and using the Thinkpad Pro Dock; after installing dock firmware version 2.17.00 linked above on Windows and rebooting into Arch, dual display (monitor model Acer V236HL) is confirmed working over DVI, including extended desktop.

Thank you to everyone that contributed to this fix.

(In reply to comment #153)
> Dual display is confirmed working after firmware upgrade.
>
> I'm dual booting Arch Linux (uname -r: kernel 3.12.9-2-ARCH) and Windows 7
> on a Thinkpad T440 and using the Thinkpad Pro Dock; after installing dock
> firmware version 2.17.00 linked above on Windows and rebooting into Arch,
> dual display (monitor model Acer V236HL) is confirmed working over DVI,
> including extended desktop.
>
> Thank you to everyone that contributed to this fix.

Elaboration: I have not applied any patches to the kernel at all. The firmware upgrade was enough in my case.

(In reply to comment #149)
> As the fix ended up being my commit, I feel I should express my view on the
> offered bounty. This is speaking solely for myself, not for my employer or
> colleagues. Regardless of the firmware fix, I think it would be unethical of
> me to accept any part of the bounty.

Thank you all very much. And very well spoken, Jani. It's a great community at work here.

Additional datapoint since I just ran into this bug but haven't yet managed to upgrade the firmware.

I am running Debian Testing right now on a new x240 with the ultradock. I was testing this and, just as gdm was about to start up, I docked the system.

Kernel is now saying "task kworker/1:3:1450 blocked for more than 120 seconds" and "task Xorg:1647 blocked for more than 120 seconds" followed by "Not tainted 3.12-1-amd64 #1"

I'll apply the firmware updates, but it I thought this might help someone who was searching for an answer.

(In reply to comment #156)
> Additional datapoint since I just ran into this bug but haven't yet managed
> to upgrade the firmware.
>
> I am running Debian Testing right now on a new x240 with the ultradock. I
> was testing this and, just as gdm was about to start up, I docked the system.
>
> Kernel is now saying "task kworker/1:3:1450 blocked for more than 120
> seconds" and "task Xorg:1647 blocked for more than 120 seconds" followed by
> "Not tainted 3.12-1-amd64 #1"
>
> I'll apply the firmware updates, but it I thought this might help someone
> who was searching for an answer.

Was this with or without the kernel patches? If without, please try with them. Thanks.

without. I haven't had time to compile a new one.

I confirm this behaviour: with the dock firmware update (T440s in a ProDock for me), I can use external displays. I can have two external displays (two 1680x1050), one on HDMI port, an another on VGA port.

In normal mode, the two external displays are mirrored.

But I can put them in extended desktop mode and have something like one 3360x1050 display. I'd preffer have two distinct displays, because today it's difficult to manage the windows size of the graphic applications (in particular, the automatic resize facility when you push the window to the bottom/top/left/right on in the corner). So, I expect an evolution.

Nevertheless, the good news is that I can use 3 displays in the same time: the internal one and the two externals.

Using Fedora 20 with kernel 3.13.6-200.fc20.x86_64 I can now use my Lenovo T440s and the ThinkPad Pro Dock and 1 external monitor. However if I connect a second monitor it just gets a mirror of the first external monitor. I can connect the first monitor to VGA or DVI and that works fine.

xrandr output with two monitor connected (same output with only one external monitor):
$ xrandr
Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 173mm
   1920x1080 60.0*+
   1400x1050 60.0
   1280x1024 60.0
   1280x960 60.0
   1024x768 60.0
   800x600 60.3 56.2
   640x480 59.9
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 459mm x 296mm
   1680x1050 60.0*+
   3360x1050 60.0
   2560x1024 60.0
   1280x1024 75.0 60.0
   1440x900 75.0 59.9
   1280x960 60.0
   1280x800 74.9 59.8
   1152x864 75.0
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 75.0 72.8 66.7 60.0
   720x400 70.1
HDMI2 disconnected (normal left inverted right x axis y axis)

(In reply to comment #159)
> Using Fedora 20 with kernel 3.13.6-200.fc20.x86_64 I can now use my Lenovo
> T440s and the ThinkPad Pro Dock and 1 external monitor. However if I connect
> a second monitor it just gets a mirror of the first external monitor. I can
> connect the first monitor to VGA or DVI and that works fine.

Duplicate of comment #122, an answer can be found in comment #128 or search for MST in this report.

(In reply to comment #159)
> DP2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis)
> 459mm x 296mm
> 1680x1050 60.0*+
> 3360x1050 60.0

This is perhaps the wrong place, but I'm curious; if you select the 3360x1050 mode, does it stretch across both monitors?

Thanks! Yes. It stretches across both monitors.

So, to my understanding MST is not supported meaning that multiple (DP) connected monitors will become mirrored. However, it seems like also the DVI output is mirrored - is this expected?

I am running Ubuntu 14.04 (i.e. 3.13.0-24-generic) on a T440p attached to an ultra dock (firmware 2.17), and attaching one DP monitor works flawlessly together with the builtin display. However attaching an additional monitor (occurs for both DP and DVI) simply mirrors the first DP connected display. xrandr outputs the same in either case:

martin@martin-ThinkPad-T440p:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected (normal left inverted right x axis y axis)
   1600x900 60.0 +
   1440x900 59.9
   1360x768 59.8 60.0
   1152x864 60.0
   1024x768 60.0
   800x600 60.3 56.2
   640x480 59.9
VGA1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200 60.0*+
   3840x1200 60.0
   2560x1024 60.0
   1920x1080 60.0
   1600x1200 60.0
   1680x1050 60.0
   1280x1024 60.0
   1440x900 59.9
   1280x800 59.8
   1280x720 60.0
   1024x768 60.0
   800x600 60.3
   640x480 60.0
   720x400 70.1
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

I would expect the DVI port to be working independently of the DP port - is this not the case?

thanks,
Martin

Im not sure but i think all outputs (DP, DVI, VGA) are converted from DP. So one big DP Hub with direct DP, VGA-converter and DVI-converter.

So no matter what we do, we can only reach a maximum of two unique displays (the builtin and one external) without MST?

i currently have 1x mDP > HDMI; 1x DVI on Dock; and builtin. so 3 displays are possible with dock and builtin. and vga on the laptop directly may be also usable. i read that MST is currently in progress by some intel devs, i think it was on phoronix.

Thanks Jan, I will try the mDP solution whenever I can get hold of an adapter/cable.

I guess the post you are referring to is this http://www.phoronix.com/scan.php?page=news_item&px=MTY1MjI

(In reply to comment #166)
> i currently have 1x mDP > HDMI; 1x DVI on Dock; and builtin. so 3 displays
> are possible with dock and builtin. and vga on the laptop directly may be
> also usable. i read that MST is currently in progress by some intel devs, i
> think it was on phoronix.

That information is wrong.

David Airlie of Red Hat is hacking on it, see http://cgit.freedesktop.org/~airlied/linux/log/?h=i915-mst-hacks

(In reply to comment #166)
> i currently have 1x mDP > HDMI; 1x DVI on Dock; and builtin. so 3 displays
> are possible with dock and builtin.

I can confirm that this setup works.

> and vga on the laptop directly may be also usable.

I've tried using it and it appears disabled when the laptop is docked.

The same problem on MacBook Air 2014 in the transition to the standby mode. After that set the brightness below 90% is not possible, the screen goes off completely. I think the problem in the module wl.
WARNING: CPU: 3 PID: 86 at drivers/gpu/drm/i915/intel_pm.c:6585 intel_display_power_put+0x15c/0x170 [i915]() [i915]