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 |
||
Created attachment 125391 [details]
"xrandr -q" with linux 3.12
Created attachment 125401 [details]
output of get-edid and parse-edid
Please attach dmesg with drm.debug=0xe module parameter. 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? (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 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.
This bug is still "NEEDINFO"... is there any other information I should provide? 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? (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. 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? (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. 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. 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 |
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.