Created attachment 110588 [details] Output of lspci -vvvnnxxx I'm using Lenovo Thinkpad T440p with a dock. A monitor with 2560x1600 resolution is connected to a DP port on the dock. The lib panel resolution is 1366x768. Linux 3.16 starts with the native resolution of the external monitor. Linux 3.17 and newer starts with the resolution of the dock (actually, a few pixels less than that, 1360x768). It can be set to the native resolution by running xrandr --output DP4 --auto Bisection gives the first bad commit: 0e32b39ceed665bfa4a77a4bc307b6652b991632 by Dave Airlie - drm/i915: add DP 1.2 MST support (v0.7) Unlike other bugs introduced by that commit, this bug is not fixed in Linux 3.18 and in the current commit on intel-drm/drm-intel-nightly, 97416b3589be60c5ece051784aa6bf34c31d86bc. xrandr shows that the new kernels recognize more DP ports. The port connected to the monitor is seen as DP2 by the old kernels and DP4 by the new kernels.
Created attachment 110589 [details] .config used by the last good and the fist bad commits
Created attachment 110590 [details] dmesg at the first bad commit
Created attachment 110591 [details] dmesg at the last good commit
Created attachment 110592 [details] Xorg log, first bad commit
Created attachment 110593 [details] Xorg log, last good commit
Created attachment 110594 [details] xrandr --verbose output, first bad commit
Created attachment 110595 [details] xrandr --verbose output, last good commit
I'm using Ubuntu 14.10 i386, fully up-to-date. The data is from a self-compiled 32-bit kernel. I tried compiling 64-bit kernels, it makes no difference. The kernel config is heavily stripped to speed up bisection, but kernels with more features exhibit the same problem. Running "xrandr -verbose" causes extra lines to appear in Xorg.0.log. They are present in the attached files. It's interesting that only one modeline is printed for old kernels, whereas many modelines are printed for the new kernels. The data for the Linux 3.18.0-00781-g97416b3 (the latest intel-drm/drm-intel-nightly) is very similar to the data for the first bad commit (0e32b39ceed665bfa4a77a4bc307b6652b991632), so I'm not attaching it.
The change is that the MST code is able to do correct discovery of the outputs below the hub. This means that the fb helper configuration then matches the common mode between the LVDS and DP resulting in a the lower resolution, i.e. working as designed.
Oh well, I liked the old behavior better. But I guess the fix should be elsewhere.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.