Bug 70331

Summary: Incorrect resolution reported for monitor
Product: Drivers Reporter: Ralf (post+kernel)
Component: Video(DRI - Intel)Assignee: Ville Syrjala (ville.syrjala)
Status: RESOLVED CODE_FIX    
Severity: normal CC: chris, daniel, intel-gfx-bugs, ville.syrjala
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.13 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: "xrandr -q" with linux 3.10
"xrandr -q" with linux 3.12
output of get-edid and parse-edid
dmesg with drm.debug=0xe, linux 3.12

Description Ralf 2014-02-09 11:40:51 UTC
Created attachment 125381 [details]
"xrandr -q" with linux 3.10

With current kernels, the tools concerning monitor resolutions (in my case, xrandr) claim that a resolution is supported by my monitor, which it does not actually support: 1920x1080. Setting that resolution results in the screen going black and asking me to properly set up the resolution.

The errornous resolution appears in "xrandr -q" output or kernel 3.12 and 3.13, but it does not appear with kernel 3.10, 3.4 and 3.2. I attached the xrandr output for both linux 3.10 and 3.12.

$ xrandr -v
xrandr program version       1.4.1
Server reports RandR version 1.4
I am using Debian testing with Xorg 1.14.5, Mesa 9.2.2.
I attached the output of "sudo get-edid | parse-edid". If there's any further information you need, please let me know.

My monitor is a Dell U2412M, a 24" screen with a native resolution of 1920x1200. It is attached via a DVI-HDMI cable to the HDMI port of the HD3000 in my Core i5-2450M.
Comment 1 Ralf 2014-02-09 11:41:26 UTC
Created attachment 125391 [details]
"xrandr -q" with linux 3.12
Comment 2 Ralf 2014-02-09 11:43:57 UTC
Created attachment 125401 [details]
output of get-edid and parse-edid
Comment 3 Jani Nikula 2014-02-10 13:14:04 UTC
Please attach dmesg with drm.debug=0xe module parameter.
Comment 4 Ralf 2014-02-11 18:54:07 UTC
That doesn't seem to work, I get

  i915: unknown parameter 'drm.debug' ignored

after putting the following into /etc/modprobe.d/i915.conf:

  options i915 drm.debug=0xe

Do I need to enable specific kernel compilation options?
Comment 5 Jani Nikula 2014-02-11 19:22:54 UTC
(In reply to Ralf Jung from comment #4)
> That doesn't seem to work, I get
> 
>   i915: unknown parameter 'drm.debug' ignored
> 
> after putting the following into /etc/modprobe.d/i915.conf:
> 
>   options i915 drm.debug=0xe
> 
> Do I need to enable specific kernel compilation options?

options drm debug=0xe
Comment 6 Ralf 2014-02-11 20:33:36 UTC
Created attachment 125641 [details]
dmesg with drm.debug=0xe, linux 3.12

I see, I wasn't aware that drm is a module on its own.

Output of dmesg is attached (with the 3.12 kernel from Debian). It seems it was cut off at the top though, hopefully that's not a problem.
Comment 7 Ralf 2014-02-28 07:47:30 UTC
This bug is still "NEEDINFO"... is there any other information I should provide?
Comment 8 Jani Nikula 2014-02-28 08:28:59 UTC
On a hunch I'd say this is caused by

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

    drm/i915: fix hdmi portclock limits

Before the change, the 172.7 MHz clock reported in edid for the 1920x1080 mode was pruned with MODE_CLOCK_HIGH, but not afterwards.

The problem is, the change is valid for HDMI. You experience the issue because you're using an HDMI->DVI adapter, and the 172.7 MHz clock exceeds the single-link DVI maximum of 165 MHz.

Since the monitor reports the mode on DVI, I presume the monitor would support the mode with dual-link DVI. But it's also possible the monitor reports a bogus mode... Anyway, simple passive adapters won't work for HDMI->dual-link-DVI. Active adapters for this are likely hard to come by, and may be problematic.

Ville, I'm wondering if we should check for intel_hdmi->has_hdmi_sink in hdmi_portclock_limit() and limit to 165 MHz for non-hdmi. Does that sounds sane to you?
Comment 9 Ville Syrjala 2014-02-28 09:02:35 UTC
(In reply to Jani Nikula from comment #8)
> Ville, I'm wondering if we should check for intel_hdmi->has_hdmi_sink in
> hdmi_portclock_limit() and limit to 165 MHz for non-hdmi. Does that sounds
> sane to you?

I posted a patch to do exactly that to another bug a few days ago:
https://bugs.freedesktop.org/show_bug.cgi?id=75345#c7

Ralf, please give that a try, and report back if it works.
Comment 10 Ralf 2014-02-28 18:29:39 UTC
With that patch on top of 3.14-rc4, the incorrect resolution is gone from "xrandr -q". Great :)

What I do not understand: 1920x1080 is less data than 1920x1200. As far as I know (and as far as Google knows ;-), 1920x1080 can be done over single-link DVI. So how can it need a higher clock speed?
Comment 11 Jani Nikula 2014-03-03 09:13:14 UTC
(In reply to Ralf Jung from comment #10)
> With that patch on top of 3.14-rc4, the incorrect resolution is gone from
> "xrandr -q". Great :)

Awesome!

> What I do not understand: 1920x1080 is less data than 1920x1200. As far as I
> know (and as far as Google knows ;-), 1920x1080 can be done over single-link
> DVI. So how can it need a higher clock speed?

The EDID of the monitor reports a larger total size and therefore a higher clock for 1920x1080 than for 1920x1200:

Modeline 22:"1920x1200" 60 154000 1920 1968 2000 2080 1200 1203 1209 1235 0x48 0x9
Modeline 27:"1920x1080" 60 172780 1920 2040 2248 2576 1080 1081 1084 1118 0x0 0x6

Why the monitor would do this is anyone's guess.
Comment 12 Daniel Vetter 2014-03-03 09:15:14 UTC
On Mon, Mar 3, 2014 at 10:13 AM,  <bugzilla-daemon@bugzilla.kernel.org> wrote:
>
> The EDID of the monitor reports a larger total size and therefore a higher
> clock for 1920x1080 than for 1920x1200:
>
> Modeline 22:"1920x1200" 60 154000 1920 1968 2000 2080 1200 1203 1209 1235
> 0x48
> 0x9
> Modeline 27:"1920x1080" 60 172780 1920 2040 2248 2576 1080 1081 1084 1118 0x0
> 0x6
>
> Why the monitor would do this is anyone's guess.

Reduced-blanking vs. non-reduced blanking. Especially 1080p often
comes with the full blanking for compat with ... analog TV.

Yep, crying over this is appropriate.
Comment 13 Jani Nikula 2014-08-14 08:28:12 UTC
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

which was amended with
commit 40478455fefdc0bde24ae872c3f88d58a1b0e435
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Mar 27 11:08:45 2014 +0200

    drm/i915: Allow user modes to exceed DVI 165MHz limit