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 #
Created attachment 131593 [details] .config 4.8.17 Highest-numbered 'working' .config
Created attachment 131594 [details] .config 4.9.1 lowest-numbered non-'working' .config
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.
Created attachment 131595 [details] dmesg output with debug=0x1e as specified Has to be compressed in order to fit into 32KB
Created attachment 131596 [details] Xorg.0.log
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.
We probably have another bug about this.
> "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.
(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.
(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.
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.
I've just observed that audio through the monitor speakers no longer works. "grep -i hda dmesg" brings up some relevant stuff.
Sorry
(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.
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.
(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.
(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~
(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.