Bug 90128 - Big monitor has blank display (HDMI or DVI) in any kernel since and including 3.13 (despite earlier fixes)
Summary: Big monitor has blank display (HDMI or DVI) in any kernel since and including...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-21 20:44 UTC by philipmorant
Modified: 2017-07-20 22:31 UTC (History)
1 user (show)

See Also:
i915 platform: HSW
i915 features: display/HDMI

Attachments
kernel4.4errormsg (23.07 KB, application/octet-stream)
2016-01-22 14:33 UTC, philipmorant 		no flags Details
dmesg with drm.debug=0xe, as requested (149.67 KB, text/plain)
2017-03-30 14:22 UTC, philipmorant 		no flags Details
dmesg (235.12 KB, text/plain)
2017-03-30 19:06 UTC, philipmorant 		no flags Details
dmesg (155.36 KB, text/plain)
2017-03-30 19:24 UTC, philipmorant 		no flags Details
View All

Description philipmorant 2015-04-21 20:44:32 UTC 
My 2560x1440 WQHD monitor works find under linux kernel 3.11 and 3.12 but shows nothing but a blank screen under 3.13 and later kernels.  It's a haswell system running on a Z97.  I have one other monitor connected, over DSUB, at 1920x1080 pixels.

The monitor accepts only dual dvi inputs.  I tried lowering the portclock by specifying refresh rates of 30Hz and lower, and while xrandr reported the monitor working with that, nothing appeared onscreen.  This monitor seems fussy about its refresh rates.

After reading other issues and setting drm.debug=0xe I discovered that the following patch to intel_hdmi.c fixes the problem for me:
@@ -849,7 +849,7 @@ static int hdmi_portclock_limit(struct intel_hdmi *hdmi, bool respect_dvi_limit)
{
    struct drm_device *dev = intel_hdmi_to_dev(hdmi);

-   if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
+   if (IS_G4X(dev))
       return 165000;
    else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
       return 300000;

Of course the ! hdmi->has_hdmi_sink check is in there for a reason, and maintainers may not consider my patch to be a fix at all.  All I can say is, it makes my monitor work.  Happy day.



*Possibly* related issues:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1215449

Definitely relevant:
https://bbs.archlinux.org/viewtopic.php?id=179120

This fix should have resolved the issue for me, but didn't:
https://bugzilla.kernel.org/show_bug.cgi?id=72961
Comment 1 Ander Conselvan de Oliveira 2015-05-12 12:38:47 UTC 
(In reply to philipmorant from comment #0)
> My 2560x1440 WQHD monitor works find under linux kernel 3.11 and 3.12 but
> shows nothing but a blank screen under 3.13 and later kernels.

What was the lastest kernel you tested?

 
> This fix should have resolved the issue for me, but didn't:
> https://bugzilla.kernel.org/show_bug.cgi?id=72961

Please clarify why this didn't work for you. Were you unable to add the high resolution mode with xrandr?
Comment 2 philipmorant 2015-05-12 14:34:41 UTC 
I tested up to kernel 3.16.  The recent ubuntu kernel update
(3.16.0.37.29) also broke my monitor and I had to reapply my patch.

As for why the bugfix that introduced the respect_dvi_limit variable
(I think it was 72961 but am not sure) didn't work for me, I think it
might be like this: there's two paths through hdmi_portclock_limit(),
one of which has respect_dvi_limit set to false, to enable the case
where the mode is being requested interactively by an xrandr user.
But the other path has respect_dvi_limit set to true, and contrary to
the expectations of the people who introduced respect_dvi_limit that
path *is* exercised when specifying modes interactively via xrandr.
I'm not in a position to say for sure, but that's what it looks like.

I've always been able on all kernels to add the right mode using
xrandr, and xrandr seems happy and reports that the display is set to
2560x1440x60 and is using it ... but there's no picture on the
monitor.
$  xrandr
...snip...
HDMI1 connected 2560x1440+1920+0 (normal left inverted right x axis y
axis) 597mm x 336mm
   2560x1440      60.0*+

I'm guessing that the monitor only works with a refresh rate of 60Hz,
which would account for why I get no picture at the in-spec refresh
rate 30Hz.
Comment 3 Jani Nikula 2016-01-18 13:16:55 UTC 
Please try kernel v4.4.
Comment 4 philipmorant 2016-01-22 14:33:06 UTC 
Created attachment 121207 [details]
kernel4.4errormsg

Hi Jani,
I've built 4.4 from kernel sources and used it with its  default
config on my ubuntu trusty system.  It boots, but the monitor problem
is not fixed.  error message attached.
Philip

On 18 January 2016 at 13:16,  <bugzilla-daemon@freedesktop.org> wrote:
> Comment # 3 on bug 90128 from Jani Nikula
>
> Please try kernel v4.4.
>
> ________________________________
> You are receiving this mail because:
>
> You reported the bug.
Comment 5 maria guadalupe 2017-02-24 22:23:59 UTC 
i review this bug with the next kernel and the problem not persist 

Kernel version : 4.10.0-0a03ea9
commit 0a03ea9496b49746b4964d05cc1f483385d1df8a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Feb 20 17:20:19 2017 +0000

please try with new kernel if this bug is not updating in 30 days i will close it
Comment 6 philipmorant 2017-02-25 10:06:30 UTC 
Where can I get the source (or kernel) from ?

On 24 February 2017 at 22:23,  <bugzilla-daemon@freedesktop.org> wrote:
> Comment # 5 on bug 90128 from maria guadalupe
>
> i review this bug with the next kernel and the problem not persist
>
> Kernel version : 4.10.0-0a03ea9
> commit 0a03ea9496b49746b4964d05cc1f483385d1df8a
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Mon Feb 20 17:20:19 2017 +0000
>
> please try with new kernel if this bug is not updating in 30 days i will
> close
> it
>
> ________________________________
> You are receiving this mail because:
>
> You reported the bug.
Comment 7 philipmorant 2017-02-25 14:23:17 UTC 
More to the point, has the code been changed ?  You don't say that it has.

On 24 February 2017 at 22:23,  <bugzilla-daemon@freedesktop.org> wrote:
> Comment # 5 on bug 90128 from maria guadalupe
>
> i review this bug with the next kernel and the problem not persist
>
> Kernel version : 4.10.0-0a03ea9
> commit 0a03ea9496b49746b4964d05cc1f483385d1df8a
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Mon Feb 20 17:20:19 2017 +0000
>
> please try with new kernel if this bug is not updating in 30 days i will
> close
> it
>
> ________________________________
> You are receiving this mail because:
>
> You reported the bug.
Comment 8 Ricardo 2017-02-27 21:51:25 UTC 
You can get the kernel from kernel.org https://www.kernel.org/ 
Looks like is fixed in latest kernel. I will put the bug as resolved 

please try it with latest kernel if the problem is solved you can close it 

if the problem is not solved for you, please set the bug to reopen and attach latest logs
Comment 9 philipmorant 2017-02-28 19:33:38 UTC 
After
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
and
git clone  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
I am unable to find commit 0a03ea9496b49746b4964d05cc1f483385d1df8a
However commit bc49a7831b1137ce1c2dda1c57e3631655f5d2ae comes a few days later than 0a03ea, and I can see that the problematic function hdmi_port_clock_limit() has been changed.  So I compiled it and tested.

The situation has not changed.  At boot up the WQHD monitor is switched off.  I can call xrandr --newmode and xrandr --addmode and xrandr --output HDMI1 ..., and xrandr (and also the ubuntu Display applet) report that they're happy, BUT the monitor is switched to standby mode, ie not showing anything.

Neither syslog nor xorg.log show any errors.  This is all:
[  1566.989] (II) intel(0): resizing framebuffer to 4480x1440
[  1567.034] (II) intel(0): switch to mode 1920x1080@60.0 on VGA1 using pipe 1, position (2560, 360), rotation normal, reflection none
[  1567.153] (II) intel(0): switch to mode 2560x1440@29.9 on HDMI1 using pipe 0, position (0, 0), rotation normal, reflection none
Comment 10 Ville Syrjala 2017-03-29 11:37:39 UTC 
(In reply to philipmorant from comment #9)
> After
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> and
> git clone  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> I am unable to find commit 0a03ea9496b49746b4964d05cc1f483385d1df8a
> However commit bc49a7831b1137ce1c2dda1c57e3631655f5d2ae comes a few days
> later than 0a03ea, and I can see that the problematic function
> hdmi_port_clock_limit() has been changed.  So I compiled it and tested.
> 
> The situation has not changed.  At boot up the WQHD monitor is switched off.
> I can call xrandr --newmode and xrandr --addmode and xrandr --output HDMI1
> ..., and xrandr (and also the ubuntu Display applet) report that they're
> happy, BUT the monitor is switched to standby mode, ie not showing anything.
> 
> Neither syslog nor xorg.log show any errors.  This is all:
> [  1566.989] (II) intel(0): resizing framebuffer to 4480x1440
> [  1567.034] (II) intel(0): switch to mode 1920x1080@60.0 on VGA1 using pipe
> 1, position (2560, 360), rotation normal, reflection none
> [  1567.153] (II) intel(0): switch to mode 2560x1440@29.9 on HDMI1 using
> pipe 0, position (0, 0), rotation normal, reflection none

Please attach a full dmesg from boot up to when you see the problem, with drm.debug=0xe passed to the kernel command line. And if possible please do so with a fresh kernel built from 'git://anongit.freedesktop.org/drm-tip drm-tip'
Comment 11 philipmorant 2017-03-30 14:21:19 UTC 
Steps Taken:

git clone git://anongit.freedesktop.org/drm-tip drm-tip

I built commit e4e6acb231bcfb81e010550990cca19cac955f91 like this:

make oldconfig
	(pressing RETURN for each option, which (I assume) accepts the default)
make
sudo make modules_install install
reboot with drm.debug=0xe

RESULTS

uname -a
	Linux sucker 4.11.0-rc4+ #1 SMP Thu Mar 30 13:21:52 BST 2017 x86_64 x86_64 x86_64 GNU/Linux
The big monitor now shows something (a breakthrough !):  vertical banding, and vertical lines which appear to be moving upwards.
Comment 12 philipmorant 2017-03-30 14:22:12 UTC 
Created attachment 130583 [details]
dmesg with drm.debug=0xe, as requested
Comment 13 Ville Syrjala 2017-03-30 15:43:33 UTC 
So the main problem here is that the monitor has a broken EDID. Whether it's really broken or just doesn't like how we're trying to do the EDID read for some reason I can't say.
[    4.546886] i915 0000:00:02.0: HDMI-A-1: EDID is invalid:
[    4.546887] 	[00] GOOD 00 ff ff ff ff ff ff 00 12 ed fa 00 00 00 00 00
[    4.546888] 	[00] GOOD 28 15 01 03 a5 3c 22 78 22 6f b1 a7 55 4c 9e 25
[    4.546888] 	[00] GOOD 0c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
[    4.546889] 	[00] GOOD 01 01 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20
[    4.546889] 	[00] GOOD 35 00 55 50 21 00 00 1a 00 00 00 fc 00 51 48 44
[    4.546889] 	[00] GOOD 32 37 30 0a 20 20 20 20 20 20 00 00 00 fc 00 0a
[    4.546890] 	[00] GOOD 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 fc
[    4.546890] 	[00] GOOD 00 0a 20 20 20 20 20 20 20 20 20 20 20 20 01 89
[    4.546891] 	[01] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.546891] 	[01] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.546891] 	[01] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.546892] 	[01] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.546892] 	[01] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.546892] 	[01] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.546893] 	[01] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.546893] 	[01] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Thanks to that broken EDID the only mode we can extract from it is 2560x144@60, which is too high for DVI, so we reject the mode. We can't tell whether the monitor is DVI or HDMI without having the CEA/HDMI block in the EDID. Whether it was supposed to be in that all 'ff' block I can't say.

In any case then userspace for some reason decides to try to use a 1360x768 mode which the monitor apparently doesn't like and instead just displays garbage.

So the way you should be able to make this work is manually adding the correct mode (assuming the monitor was previously happy with out of spec DVI signal, but from the explanation I got the impression that that indeed was the case).

As for the EDID fail, you could perhaps try this patch just to make sure we don't have some GMBUS bug in the code causing this problem:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b6401e8f1bd6..8780f411afa9 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -665,7 +665,7 @@ int intel_setup_gmbus(struct drm_i915_private *dev_priv)
                bus->reg0 = pin | GMBUS_RATE_100KHZ;
 
                /* gmbus seems to be broken on i830 */
-               if (IS_I830(dev_priv))
+               if (1||IS_I830(dev_priv))
                        bus->force_bit = 1;
 
                intel_gpio_setup(bus, pin);

Or if you have a non-Intel GPU around you could perhaps try to see if you can read the full EDID on that one.
Comment 14 philipmorant 2017-03-30 19:06:01 UTC 
Created attachment 130590 [details]
dmesg

Trying manual xrandr:

xrandr --newmode "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync
xrandr --addmode HDMI1  2560x1440_60.00

screen goes blank.  gnome is treating it as switched off.
xrandr:
Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767
HDMI1 connected primary (normal left inverted right x axis y axis)
   2560x1440_60.00  59.96
HDMI2 disconnected (normal left inverted right x axis y axis)
VGA1 connected 1920x1080+2560+360 (normal left inverted right x axis y axis) 478mm x 269mm
   1920x1080     60.00*+
   1680x1050     59.95
   1280x1024     75.02
   1440x900      74.98    59.89
   1280x960      60.00
   1280x800      59.81
   1152x864      75.00
   1280x720      60.00
   1152x720      59.97
   1024x768      75.03    70.07    60.00
   832x624       74.55
   800x600       72.19    75.00    60.32    56.25
   640x480       75.00    72.81    66.67    59.94
   720x400       70.08
VIRTUAL1 disconnected (normal left inverted right x axis y axis)


xrandr --newmode "2560x1440_30.00"  146.25  2560 2680 2944 3328  1440 1443 1448 1468 -hsync +vsync
xrandr --addmode HDMI1  2560x1440_30.00
xrandr --output HDMI1 --mode 2560x1440_30.00

The screen is still blank, but the system is treating the monitor as switched on (gnome adds 'switch to monitor right' menu option for windows.  Also, the panel is now not visible because gnome has put it on the big monitor.)

xrandr:
Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767
HDMI1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440     29.94*+
   2560x1440_60.00  59.96  
   2560x1440_30.00  29.94  
HDMI2 disconnected (normal left inverted right x axis y axis)
   2560x1440_30.00  29.94  
VGA1 connected 1920x1080+2560+360 (normal left inverted right x axis y axis) 478mm x 269mm
   1920x1080     60.00*+
   1680x1050     59.95  
   1280x1024     75.02  
   1440x900      74.98    59.89  
   1280x960      60.00  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00  
   1152x720      59.97  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   640x480       75.00    72.81    66.67    59.94  
   720x400       70.08  
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Comment 15 philipmorant 2017-03-30 19:24:44 UTC 
Created attachment 130591 [details]
dmesg

Trying with the gmbus patch as given above:

Same results.  dmesg output attached (with drm.debug=0xe).
Comment 16 Ville Syrjala 2017-03-30 20:05:10 UTC 
(In reply to philipmorant from comment #14)
> Created attachment 130590 [details]
> dmesg
> 
> Trying manual xrandr:
> 
> xrandr --newmode "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443
> 1448 1493 -hsync +vsync
> xrandr --addmode HDMI1  2560x1440_60.00
> 
> screen goes blank.  gnome is treating it as switched off.

HSW doesn't support > 300 MHz clock with HDMI
[  160.088402] [drm:intel_hdmi_compute_config [i915]] unsupported HDMI clock, rejecting mode

The only mode the EDID shows is:
xrandr --newmode "2560x1440" 241.5 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync

And the mode used by the BIOS would be:
xrandr --newmode "1024x768" 65.0 1024 1048 1184 1344 768 771 777 806 -hsync -vsync

Can you try either of those?
Comment 17 philipmorant 2017-03-30 22:45:42 UTC 
xrandr --newmode "2560x1440" 241.5 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync

Works !
But this was the gmbus-patched code.  Does that matter ?
                                                                                                                                                      
xrandr --newmode "1024x768" 65.0 1024 1048 1184 1344 768 771 777 806 -hsync -vsync

X Error of failed request:  BadName (named color or font does not exist)                                                                           
     Major opcode of failed request:  140 (RANDR)                                                                                                     
     Minor opcode of failed request:  16 (RRCreateMode)                                                                                               
     Serial number of failed request:  37                                                                                                             
     Current serial number in output stream:  37
Comment 18 Ricardo 2017-07-20 22:31:26 UTC 
looks like this bug is fixed by a workaround because of a limitation support on specific platform.. closing bug

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.