Bug 101245 - Haswell ULT max. resolution regression in KMS [HSW] [i915]
Summary: Haswell ULT max. resolution regression in KMS [HSW] [i915]
Status: CLOSED NOTABUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-31 09:49 UTC by Michael Mounteney
Modified: 2017-06-30 20:21 UTC (History)
2 users (show)

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


Attachments
.config 4.8.17 (102.94 KB, text/x-mpsub)
2017-05-31 09:51 UTC, Michael Mounteney
no flags Details
.config 4.9.1 (103.16 KB, text/x-mpsub)
2017-05-31 09:51 UTC, Michael Mounteney
no flags Details
dmesg output with debug=0x1e as specified (26.10 KB, application/octet-stream)
2017-05-31 10:44 UTC, Michael Mounteney
no flags Details
Xorg.0.log (15.79 KB, text/x-log)
2017-05-31 10:45 UTC, Michael Mounteney
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Mounteney 2017-05-31 09:49:57 UTC
With a 4.8.17 kernel or earlier, console graphics is set (as expected) to 2560x1600 with HDMI connected to a suitable monitor.

    # lspci|grep -i vga
    00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09)

:With a 4.9.1 or later kernel, using a .config taken from a working configuration, resolution is 1920x1200.  When it is so set, this sequence of commands, within a terminal window in an X session, does not effect any increase in resolution:

    # cvt 2560 1600
    # 2560x1600 59.99 Hz (CVT 4.10MA) hsync: 99.46 kHz; pclk: 348.50 MHz
    Modeline "2560x1600_60.00"  348.50  2560 2760 3032 3504  1600 1603 1609 1658 -hsync +vsync
    # xrandr --newmode "2560x1600_60.00"  348.50  2560 2760 3032 3504  1600 1603 1609 1658 -hsync +vsync
    # xrandr --addmode HDMI1 "2560x1600_60.00"
    # xrandr --output HDMI1 --mode 2560x1600_60.00 --verbose
    screen 0: 2560x1600 676x422 mm  96.15dpi
    crtc 0: 2560x1600_60.00  59.99 +0+0 "HDMI1"
    xrandr: Configure crtc 0 failed
    crtc 0: disable
    crtc 1: disable
    crtc 2: disable
    crtc 3: disable
    screen 0: revert
    crtc 0: revert
    crtc 1: revert
    crtc 2: revert
    crtc 3: revert
    #
Comment 1 Michael Mounteney 2017-05-31 09:51:16 UTC
Created attachment 131593 [details]
.config 4.8.17

Highest-numbered 'working' .config
Comment 2 Michael Mounteney 2017-05-31 09:51:59 UTC
Created attachment 131594 [details]
.config 4.9.1

lowest-numbered non-'working' .config
Comment 3 Jari Tahvanainen 2017-05-31 10:13:46 UTC
Michael - please start kernel with debug mode by adding drm.debug=0x1e log_buf_len=1M to kernel cmd line. Attach dmesg (and maybe also XOrg.0.log) as instructed in https://01.org/linuxgraphics/documentation/how-report-bugs.
Comment 4 Michael Mounteney 2017-05-31 10:44:50 UTC
Created attachment 131595 [details]
dmesg output with debug=0x1e as specified

Has to be compressed in order to fit into 32KB
Comment 5 Michael Mounteney 2017-05-31 10:45:50 UTC
Created attachment 131596 [details]
Xorg.0.log
Comment 6 Jani Nikula 2017-06-02 09:19:02 UTC
Apparently HDMI->DVI dual mode adapter where we aren't able to infer the capabilities of the sink, and limit the clock rate to what we know works. The alternative was black screens where it didn't work. It should be possible to work around this by adding user modes with xranrd.
Comment 7 Jani Nikula 2017-06-02 09:19:30 UTC
We probably have another bug about this.
Comment 8 Michael Mounteney 2017-06-02 10:32:50 UTC
> "Apparently HDMI->DVI dual mode adapter where we aren't able to infer the capabilities of the sink, and limit the clock rate to what we know works."
It did work up to 4.8.17.  I am using an Intel NUC with mini-HDMI to HDMI.  No DVI-anything involved.

> "It should be possible to work around this by adding user modes with xranrd."
As per my original description, xrandr user modes do not work.
Comment 9 Ville Syrjala 2017-06-02 10:57:43 UTC
(In reply to Michael Mounteney from comment #8)
> > "Apparently HDMI->DVI dual mode adapter where we aren't able to infer the capabilities of the sink, and limit the clock rate to what we know works."
> It did work up to 4.8.17.  I am using an Intel NUC with mini-HDMI to HDMI. 
> No DVI-anything involved.

[    2.488338] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)

Means there is no DP++ dongle involved.

[   11.111354] [drm:drm_add_edid_modes [drm]] HDMI: DVI dual 1, max TMDS clock 250000 kHz

This means the display itself is telling us that its max TMDS clock is lower than clock required by the 4k and 25x16 modes. The fact that it's saying dual link DVI and max TMDS clock > 165MHz in the same sentence is also a bit nonsensical since that exceeds the DVI spec, and dual link HDMI doesn't actually exist.

I suppose we were ignoring the limits declared by the sink before I added the DP dual mode stuff, and hence we allowed the out of spec modes through.

> 
> > "It should be possible to work around this by adding user modes with xranrd."
> As per my original description, xrandr user modes do not work.

You should use the same mode as the EDID has instead of trying CVT. The EDID seems to have something like this:
"2560x1600" 268.5 2560 2608 2640 2720 1600 1603 1609 1646 +hsync +vsync

which seems to be almost the same as what 'cvt -r' would give you apart from the vsync polarity.
Comment 10 Jani Nikula 2017-06-02 11:57:21 UTC
(In reply to Ville Syrjala from comment #9)
> (In reply to Michael Mounteney from comment #8)
> > > "Apparently HDMI->DVI dual mode adapter where we aren't able to infer the capabilities of the sink, and limit the clock rate to what we know works."
> > It did work up to 4.8.17.  I am using an Intel NUC with mini-HDMI to HDMI. 
> > No DVI-anything involved.
> 
> [    2.488338] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr:
> 0040 w(1)
> 
> Means there is no DP++ dongle involved.
> 
> [   11.111354] [drm:drm_add_edid_modes [drm]] HDMI: DVI dual 1, max TMDS
> clock 250000 kHz
> 
> This means the display itself is telling us that its max TMDS clock is lower
> than clock required by the 4k and 25x16 modes. The fact that it's saying
> dual link DVI and max TMDS clock > 165MHz in the same sentence is also a bit
> nonsensical since that exceeds the DVI spec, and dual link HDMI doesn't
> actually exist.

Thanks for the clarification, Ville. I quickly looked at the dmesg, and refused to believe the display would do this. No idea why.
Comment 11 Michael Mounteney 2017-06-03 02:41:31 UTC
Thank you for the correction on the xrandr commands.  I confirm that your settings work, and that the display is switched to 2560x1600.

I now have to find a way to incorporate the commands into my userspace start-up sequence, since currently I run lightdm and have to run "DISPLAY=:0 konsole" as root in another virtual console, to be able to enter the xrandr commands and have them take effect.

The display is a cheap unbranded Korean one.  It has a dual-link DVI-D connector, an HDMI and a VGA.  The Haswell-ULT computer is connected to the HDMI.  To the dual-link DVI-D is connected another Linux computer running 4.10.11 with this graphics adaptor:

> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6250]

and this displays at 2560x1600.  I switch between the two using input selector buttons on the monitor bezel.

To be honest, I don't fully understand Villes explanation but if the monitor really is returning nonsense in its EDID then I suppose GIGO applies and this bug should be closed.  Maybe we need CONFIG_DISTRUST_CRAPPY_LYING_EDID or similar.
Comment 12 Michael Mounteney 2017-06-04 08:21:31 UTC
I've just observed that audio through the monitor speakers no longer works.  "grep -i hda dmesg" brings up some relevant stuff.
Comment 13 Michael Mounteney 2017-06-07 01:00:16 UTC
Sorry
Comment 14 Ville Syrjala 2017-06-20 09:03:44 UTC
(In reply to Michael Mounteney from comment #11)
> Thank you for the correction on the xrandr commands.  I confirm that your
> settings work, and that the display is switched to 2560x1600.

Excellent.

> The display is a cheap unbranded Korean one.  It has a dual-link DVI-D
> connector, an HDMI and a VGA.  The Haswell-ULT computer is connected to the
> HDMI.  To the dual-link DVI-D is connected another Linux computer running
> 4.10.11 with this graphics adaptor:
> 
> > 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6250]

OK, so if we have a pure single link DVI/HDMI for the HSW it seems we're doing the right thing. It's just more a matter of luck that the single link also works for these high resolutions which according to the EDID should require dual link.

I guess I'll just mark this as a NOTABUG because everything seems to work as intended.
Comment 15 Michael Mounteney 2017-06-20 11:49:43 UTC
So everything works as intended but the monitor no longer switches to the highest resolution.

It seems that the problem is that the EDID is reporting single-link, which is relevant to DVI-D, but my connection is HDMI.  Doesn't it make sense to ignore any single-link/dual-link information with an HDMI connection?  Possibly with CONFIG_HDMI_IGNORE_LINK_ARITY ?

If you aren't prepared to do this, could you at least supply an indication of where to hack the source;  otherwise I am stuck on kernel 4.7.4 for ever, or for at least as I continue to use Linux.
Comment 16 Ville Syrjala 2017-06-20 12:22:25 UTC
(In reply to Michael Mounteney from comment #15)
> So everything works as intended but the monitor no longer switches to the
> highest resolution.
> 
> It seems that the problem is that the EDID is reporting single-link, which
> is relevant to DVI-D, but my connection is HDMI.  Doesn't it make sense to
> ignore any single-link/dual-link information with an HDMI connection? 
> Possibly with CONFIG_HDMI_IGNORE_LINK_ARITY ?
> 
> If you aren't prepared to do this, could you at least supply an indication
> of where to hack the source;  otherwise I am stuck on kernel 4.7.4 for ever,
> or for at least as I continue to use Linux.

The monitor is basically telling us that you need dual link DVI to reach the highest resolutions, but HDMI is always single link (and Intel hardware can't do dual link DVI anyway) so we high resolution modes get filtered out.

One option to overcome this would be to hack the EDID to remove/increase the TMDS clock limit (and fix up the checksum appropriately), and then use the firmware EDID load mechanism to override the EDID with the hacked version. That wouldn't require any code changes, and wouldn't require the use of custom modelines.
Comment 17 keqiao 2017-06-22 06:11:52 UTC
(In reply to Michael Mounteney from comment #12)
> I've just observed that audio through the monitor speakers no longer works. 
> "grep -i hda dmesg" brings up some relevant stuff.

I cannot reproduced this issue on my HSW NUC, I used the latest mainline kernel(Linux 4.12.0-rc6+ 48b6bbef9a1789f0365c1a385879a1fea4460016) to test and both DP and HDMI audio are working well. 
I'm not sure if this is still a issue for you, if yes, please help to post the dmesg here. 
Thanks~
Comment 18 Elizabeth 2017-06-30 20:21:47 UTC
(In reply to keqiao from comment #17)
> (In reply to Michael Mounteney from comment #12)
> > I've just observed that audio through the monitor speakers no longer works. 
> > "grep -i hda dmesg" brings up some relevant stuff.
> 
> I cannot reproduced this issue on my HSW NUC, I used the latest mainline
> kernel(Linux 4.12.0-rc6+ 48b6bbef9a1789f0365c1a385879a1fea4460016) to test
> and both DP and HDMI audio are working well. 
> I'm not sure if this is still a issue for you, if yes, please help to post
> the dmesg here. 
> Thanks~

Hello everyone,
Since this bug seems to be fixed and no more information is available, I'm going to change the status to CLOSED. If there is any new relevant information for this case, please share it and mark as REOPEN. Thank you.


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.