Created attachment 93108 [details] Kernel Log System environment: -- chipset: i7-4500U / HD 4400 -- system architecture: 64-bit -- xf86-video-intel: 2:2.99.904-0ubuntu2.1 -- xserver: 7.7+1ubuntu6 -- mesa: n/a -- libdrm: 2.4.46-1ubuntu1 -- kernel: 3.13 (native 3.11 Distrokernel of Xubuntu 13.10 showed same behaviour) -- Linux distribution: Xubuntu 13.10 -- Machine or mobo model: Lenovo ThinkPad Yoga S1 -- Display connector: DisplayPort This laptop only has a Mini-HDMI port builtin, however using a Docking Station (OneLink Pro Dock) one gets a native DisplayPort (no USB graphics). Attaching a monitor to the DP-Port of the Dock (Dell U2713HM, with 2560x1440 native resolution), running xrandr it will only show resolutions up to 1920x1200 and these modes seem to be usable. Trying to override the mode (using newmode, addmode and --output DP1 --mode ...) results in "Configure crtc 1 failed" with both the EDID-provided values and manually cvt-generated values. Judging by the Kernel log (attached), the DRM parses the EDID correctly but discards the 2560x1440 mode it provides. As the monitor only supports its native Resolution over DP and I don't have any other Monitors with such a resolution I couldn't test if using the Mini-HDMI Port on the Laptop would allow for more than 1920x1200. The monitor connected to the same machine and dock runs fine under Windows with its native resolution 2560x1440. It also works perfectly fine on Linux on my ThinkPad T420s (i5-2520M).
Created attachment 93109 [details] intel_reg_dumper output
Created attachment 93110 [details] Xrandr --verbose output
Annoyingly we don't print out the debug information about the link prior to discarding the mode, but the issue here is that the bandwidth required to send the full 2560x1440 is greater than the number of DP lanes connecting to the dock (which one presumes was penny pinched to only support 1080p).
Well Lenovo claims to support up to 2560x1600 on the DisplayPort of that Dock. And I can confirm it works with the same setup if I just boot to Windows. I then get 2560x1440@60Hz using that same dock. I can try to get you any debug information on Windows when the display is running in that resolution if you tell me what I need to do.
Created attachment 93112 [details] [review] Print link capabilities first This will be a bit verbose since we print it when validating each mode, but it should help you work out why it fails here...
Created attachment 93113 [details] [review] Print link capabilities first Ff uploaded the wrong patch
Created attachment 93114 [details] [review] Print link capabilities first ...because I did not hit git add.
Created attachment 93116 [details] [review] Print link capabilities first This is getting ridiculous!
Thanks. I will try to get back to you with the logs hopefully later today. Here is another clue I got from the dock manufacturer page: DisplayPort with maximum resolution 2560x1600* DVI-I with maximum 1920x1200 resolution and DVI to VGA adapter included in the box * Maximum resolution of 1920 x 1200 supported if second monitor is attached to DVI output. Please excuse my wild guessing as I don't really have expertise in this area: Maybe the driver/DRM doesn't really make that distinction and just always assumes the maximum resolution is 1920x1200 on the DP as opposed to Windows which seems to behave differently then. Also obviously I don't have anything attached to that DVI-port.
The values we are using are determined by talking with the DP device - they are drawn directly from the DPCD (DisplayPort configuration data) which is negotiated between the two hardware endpoints. There might be something else we have to program to disable something in the dock and renegotiate for more bandwidth - that I do not know.
(In reply to comment #3) > Annoyingly we don't print out the debug information about the link prior to > discarding the mode, but the issue here is that the bandwidth required to > send the full 2560x1440 is greater than the number of DP lanes connecting to > the dock (which one presumes was penny pinched to only support 1080p). Only two lanes but both the sink and source (Haswell) support 5.4 GHz bandwidth. It should be enough. Driver support was only just merged in commit 06ea66b6bb445043dc25a9626254d5c130093199 Author: Todd Previte <tprevite@gmail.com> Date: Mon Jan 20 10:19:39 2014 -0700 drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices which isn't upstream yet. Did you try drm-intel-nightly?
Wow, thank you so much. With the drm-intel-nightly kernel, it works like a charm.
(In reply to comment #12) > Wow, thank you so much. With the drm-intel-nightly kernel, it works like a > charm. \o/ Unfortunately, I don't think this made it in the 3.14 kernel, so it will be in 3.15. In the mean time, I urge you to keep running our nightly kernel, and report any issues you might find! ;)
Yeah I will let you know if I can find anything out of the ordinary. I added the hint to the OneLink Pro dock to the title so it might be easier to find for other users running into the same issue.
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.