Created attachment 82608 [details] Xorg.0.log Bug description: Both kernel 3.9 and 3.10 (and Windows 8) allow my first monitor to be set to its native QHD via HDMI. With 3.11-rc1 and drm-intel (nightly at 1bc20142, "Merge remote-tracking […]") setting to QHD fails and HD 1080 is the max: [ 27.838] (II) intel(0): switch to mode 2560x1440 on pipe 0 using HDMI1 [ 28.056] (EE) intel(0): failed to set mode: Invalid argument The display itself will refuse to display anything and only state "no signal" while turning itself on and off. System environment: * Haswell 4770 * Z87 (Gigabyte G1.Sniper M5 with bios F6h) * Arch Linux x65 * no dedicated graphics card * CrossOver 2730MD-P LED (2560x1440) on HDMI1 * iiyama E2773HDS (1920x1080) on HDMI2 * Arch Linux x64 * xf86-video-intel: git 6c8b15d3 (sna: Wrap cpuid.h) * xserver: git 74469895 (dix: allow a ConstantDeceleration between 0 and 1 (#66134)) * mesa: git 0d7f0874 (r600g: use WAIT_3D_IDLE before using CP DMA) * libdrm: git c6d73cfe (libdrm: bump to 2.4.46) Additional info: While the QHD was never immediatelly selectable through xrandr, the Intel driver always reports the necessary properties for manually adding the modeline: [ 27.092] (II) intel(0): Supported detailed timing: [ 27.092] (II) intel(0): clock: 241.5 MHz Image Size: 597 x 336 mm [ 27.092] (II) intel(0): h_active: 2560 h_sync: 2600 h_sync_end 2632 h_blank_end 2720 h_border: 0 [ 27.092] (II) intel(0): v_active: 1440 v_sync: 1443 v_sync_end 1448 v_blanking: 1481 v_border: 0 This was added as two lines for the HDMI1 Monitor section and one for the Screen section in 10-screens.conf. Can't dump the Video BIOS as that "echo 1 > […]" command only results in "file already exists".
Created attachment 82609 [details] dmesg with drm.debug=0.06
Created attachment 82611 [details] Xorg's screen config, working in 3.9 and 3.10
Created attachment 82612 [details] xrandr --verbose
Created attachment 82614 [details] intel_reg_dumper
Wouldn't have thought to find the responsible commit on the first try. It's "drm/i915: fixup 12bpc hdmi dotclock handling": http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=325b9d048810f7689ec644595061c0b700e64bce Reverted that, now QHD works again.
Can you add a printk() there to dump the pipe bpp? From your Xorg log we should only be requesting a depth 24 framebuffer, so I am guessing that it is the new check for mode->clock > 225000 that is failing. If you make the debug message: DRM_DEBUG_KMS("too high HDMI clock (%d > 225000), rejecting mode\n", adjusted_mode->clock); and then attach the fresh drm.debug=6 dmesg.
Waitasec... 2560x1440@60 is out-of-spec for single link HDMI and we don't implement HDMI1.4 yet... Looks like we fluked out.
Created attachment 82767 [details] [review] fix hdmi port clock limits on haswell Please test the attached patch.
Created attachment 82770 [details] [review] fix hdmi port clock limits on haswell v2 Oops, this is the right thing.
Just came back; sorry for not testing that debug message. But anyway, your patch indeed resolves the issue.
Not so fast, we keep bugs open until the patch has landed in a tree somewhere ;-) Otherwise just too much stuff gets lost. But thanks for the quick response, I've now submitted your patch to the mailing list with your tested-by attached.
Created attachment 82801 [details] [review] patch v3 This one is correct to no longer filter modes bigger than 1080p, so you should need to manually add the mode yourselves any longer. Please retest.
I've removed the relevant three lines from my 10-screens.conf. Xorg.0.log now contains "+hsync -vsync (88.8 kHz eP)" instead of "-hsync +vsync (88.8 kHz UP)". But the monitor itself indeed works fine automatically now.
Patch merged to -fixes as: commit 363202bb22467ea1de6dd284b78eff5cf517db66 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jul 22 18:02:39 2013 +0200 drm/i915: fix hdmi portclock limits
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.