Bug 75345

(In reply to comment #0)
> Given that lower resolutions work, I am wondering whether the driver does
> not correctly implement dual-link DVI?  Is this correct?

That's correct, and I think WONTFIX. I'm slightly surprised a Haswell would have a DVI port; what kind of machine is this? Are you using some adapter?

It should work with a DP to dual-link DVI adapter though.

I hesitated closing as WONTFIX as I suspect this may actually be fixed by

commit 7d148ef51a657fd04036c3ed7803da600dd0d451 [v3.11]
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Jul 22 18:02:39 2013 +0200

    drm/i915: fix hdmi portclock limits
    
    In
    
    commit 325b9d048810f7689ec644595061c0b700e64bce
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri Apr 19 11:24:33 2013 +0200
    
        drm/i915: fixup 12bpc hdmi dotclock handling
    
    I've errornously claimed that we don't yet support the hdmi 1.4
    dotclocks > 225 MHz on Haswell. But a bug report and a closer look at
    the wrpll table showed that we've supported port clocks up to 300MHz.
    
    With the new code to dynamically compute wrpll limits we should have
    no issues going up to the full 340 MHz range of hdmi 1.4, so let's
    just use that to fix this regression. That'll allow 4k over hdmi for
    free!
    
    v2: Drop the random hunk that somehow slipped in.
    
    v3: Cantiga has the original HDMI dotclock limit of 165MHz. And also
    patch up the mode filtering. To do so extract the dotclock limits into
    a little helper function.
    
    v4: Use 300MHz (from Bspec) instead of 340MHz (upper limit for hdmi
    1.3), apparently hw is not required to be able to drive the highest
    dotclocks. Suggested by Damien.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67048
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
    Tested-by: Andreas Reis <andreas.reis@gmail.com> (v2)
    Cc: Damien Lespiau <damien.lespiau@intel.com>
    Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

but there is no indication of system configuration.

Thanks for your reply.

It's an Intel DH87MC motherboard[1], which has DP, DVI and HDMI outputs.  I was hoping to use the DVI port in dual-link, so the single DP is free to daisy-chain a couple of screens which otherwise wouldn't have the bandwidth if I had to stick 2560x1600 on it as well.

Is it a lot of work to enable dual-link?  I'd be willing to have a go myself if it's something mere mortal programmers would have a chance of doing since, after all, the only reason I purchased this board was to get open source graphics drivers!

I will however, see if I can compile a version with the above commit if I'm not running it already and report back.

[1] http://ark.intel.com/products/69045/intel-desktop-board-dh87mc

(In reply to comment #3)
> Is it a lot of work to enable dual-link?  I'd be willing to have a go myself
> if it's something mere mortal programmers would have a chance of doing
> since, after all, the only reason I purchased this board was to get open
> source graphics drivers!

Yes. The hardware itself has never supported dual-link; so it would take quite a bit of work to retrofit. ;-)

(Instead of adopting dual-link, Intel developed a higher bandwidth connector, DisplayPort - unfortunately the world has been slow jumping on the bandwagon.)

(In reply to comment #2)
> I hesitated closing as WONTFIX as I suspect this may actually be fixed by
> 
> commit 7d148ef51a657fd04036c3ed7803da600dd0d451 [v3.11]
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Mon Jul 22 18:02:39 2013 +0200
> 
>     drm/i915: fix hdmi portclock limits

...

> but there is no indication of system configuration.

Heh, as you can see I hesitated closing this also.

IIUC dual-link DVI does not work with the Windows driver either (but I have no confirmation). I'm a bit on thin ice here, but I don't think increasing the HDMI frequency directly helps dual-link DVI unless there's some active components supporting dual-link. It depends on how the DVI port is set up I guess.

Adam, are you running at least kernel v3.11?

The other thing to remember is that the monitor will not advertise a dual-link mode to -intel (because it using the wrong connector). Therefore I feel reasonably confident that if it is in the EDID then we are pruning it, which should then be fixable by bumping our clock limits to the hw maximum.

Created attachment 94640 [details] [review]
drm/i915: Reject >165MHz modes w/ DVI monitors

I think the real bug here is getting a black screen because we fail to filter out the modes requiring dual-link operation. I think this patch should fix it.

I'm not sure if we should additionally reject such modes when the HDMI VSDB indicates that the monitor support dual-link DVI. The spec seems to leave open the possibility of supporting both dual-link and >165MHz over a single link, and there's no way to tell the difference between monitors that do that, and monitors that only support higher pixel clocks through dual-link DVI.

Looks like you're right - I checked the specs, and a few weeks after I bought the board the spec was updated to say the max DVI res was 1920x1200@60Hz.  I wish they'd just supplied a couple of DP ports and a DVI adapter instead...

(In reply to comment #4)
> (Instead of adopting dual-link, Intel developed a higher bandwidth
> connector, DisplayPort - unfortunately the world has been slow jumping on
> the bandwagon.)

Ironically of my four screens, two of them support DisplayPort but I can't connect them both via DP because the Intel motherboard doesn't provide enough DP connectors!

(In reply to comment #5)
> IIUC dual-link DVI does not work with the Windows driver either (but I have
> no confirmation). I'm a bit on thin ice here, but I don't think increasing
> the HDMI frequency directly helps dual-link DVI unless there's some active
> components supporting dual-link. It depends on how the DVI port is set up I
> guess.

I guess this might affect the maximum resolution possible over single-link DVI, but I believe this monitor will only sync with 1920x1200@60Hz over single-link, so any bandwidth increases over the single link won't work.  I believe this because there's a HDMI input but it only supports up to 1920x1200@60Hz.  I also tried a modeline for 2560x1600@30Hz (native res, and refresh rate that just fits within single-link's bandwidth) but the monitor came up saying the vertical refresh was out of range.

> Adam, are you running at least kernel v3.11?

I'm running kernel 3.13.4, and last tested the dual-link under 3.12.

(In reply to comment #6)
> The other thing to remember is that the monitor will not advertise a
> dual-link mode to -intel (because it using the wrong connector). Therefore I
> feel reasonably confident that if it is in the EDID then we are pruning it,
> which should then be fixable by bumping our clock limits to the hw maximum.

At least under kernel 3.12 with the DVI-D dual-link cable, it was showing 2560x1600@60Hz as a valid mode and KMS was selecting it by default, resulting in no picture shortly after boot.  I think the monitor is advertising all modes and expecting the driver to prune it if dual-link is unavailable.

In summary, it looks like Chris is right and the hardware is not dual-link capable.  So I guess the bug is that the driver attempts to set a dual-link mode when it is not achievable.

I should add the DVI output is reported by KMS as a HDMI output, so perhaps it's not possible to identify it as a DVI port and limit the bandwidth?  If this is correct, then in theory one should be able to connect a HDMI 1.4 capable monitor (not mine) to the DVI port with a passive adapter, and get 2560x1600@60Hz.

Regression since the hdmi dotclock patch broke stuff ...

(In reply to comment #8)
> I should add the DVI output is reported by KMS as a HDMI output, so perhaps
> it's not possible to identify it as a DVI port and limit the bandwidth?  If
> this is correct, then in theory one should be able to connect a HDMI 1.4
> capable monitor (not mine) to the DVI port with a passive adapter, and get
> 2560x1600@60Hz.

In theory, yes. You are still going beyond the cable spec so there is some danger that you would lose the signal.

If we ignore the ongoing issue with HDMI->active dual-DVI links, this here bug is fixed by

commit 6375b768a9850b6154478993e5fb566fa4614a9c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Mar 3 11:33:36 2014 +0200

    drm/i915: Reject >165MHz modes w/ DVI monitors
    
    Single-link DVI max dotclock is 165MHz. Filter out modes with higher
    dotclock when the monitor doesn't support HDMI.
    
    Modes higher than 165 MHz were allowed in
    
    commit 7d148ef51a657fd04036c3ed7803da600dd0d451
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Mon Jul 22 18:02:39 2013 +0200
    
        drm/i915: fix hdmi portclock limits
    
    Also don't attempt to use 12bpc mode with DVI monitors.
    
    Cc: Adam Nielsen <a.nielsen@shikadi.net>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331
    Tested-by: Ralf Jung <post+kernel@ralfj.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Thanks all for the fix!  Would it also be possible to get the wiki page updated here?

http://www.x.org/wiki/IntelGraphicsDriver/

It currently says dual-link support is "UNKNOWN" where it should really read "N/A" since we've now confirmed it's unsupported by the hardware.

My resolution went from 2560x1440 to 1920x1200 after a recent upgrade within Debian/Jessie.

After long search, I finally found the discussion at https://bbs.archlinux.org/viewtopic.php?id=179120, from which I learned that this is a driver bug (possibly declared feature) in the Intel driver and that it only affects DVI cables. So I switched to a DisplayPort cable, and my full resolution was back.

I understand almost nothing of your discussions, but I would like to emphasize that this recent change in the driver is quite annoying, and should not be allowed into a stable distribution.

(In reply to comment #12)
> I understand almost nothing of your discussions, but I would like to
> emphasize that this recent change in the driver is quite annoying, and
> should not be allowed into a stable distribution.

As annoying as it sounds, the resolution/mode you consider a feature was actually a regression to some other people, and according to them it should not have been allowed into a stable distribution either. The kernel has a fairly strict policy of the earliest regression winning, i.e. in this case we should revert back to the behaviour prior to enabling what you see as a feature.

Obviously we'll try to fix it for both, but it's not looking exactly trivial.