Created attachment 131844 [details] dmesg when there is no output after refresh toggle System architecture: x86_64 Kernel version: 4.11.4 (this also happened with the 4.10.x series.) Linux distribution: Ubuntu 17.04 Motherboard model: Gigabyte GA-H270N-WIFI CPU: Intel Kaby Lake i7-7700 Display connector: HDMI (port 1) Display chain: HDMI-1 to Pulse-eight HDMI-CEC box to Denon AVR-E400 to Panasonic 55" CX850 4K display. I am feeding the EDID and setting the mode on boot via kernel options: drm_kms_helper.edid_firmware=HDMI-A-1:edid/panasonic-denon-edid.bin video=HDMI-A-1:1920x1080@60 I having sporadic issues toggling between refresh rates. I am running Kodi on the machine which changes the refresh rate to match the frame rate of video. This usually results in toggling between 60 Hz and 59.94 Hz or 24 Hz depending upon the video. I can reproduce it with just xrandr commands as well. Toggling between two refresh rates: xrandr --output HDMI-1 --mode 1920x1080 --rate 60 xrandr --output HDMI-1 --mode 1920x1080 --rate 59.94 results in a black screen about 1 out of 3 tries with no audio over HDMI. xrandr -q still shows connected in this state at the new refresh rate, but there is no video or audio output. Toggling back to the previous refresh rate usually brings the display and audio back. I've attached a dmesg taken during a black screen after a refresh toggle. I will attach xrandr --verbose and a dmesg taken after a successful refresh change.
Created attachment 131845 [details] dmesg after several refresh rate toggles with successful change
Created attachment 131846 [details] xrandr --verbose output
I am using the xf86-video-modesetting driver with Xorg 1.9.3, but this also happens with the xf86-video-intel driver as well.
Adding tag into "Whiteboard" field - ReadyForDev *Status is correct *Platform is included *Feature is included *Priority and Severity correctly set *Logs included
Do you need any more information from me on this? Has anyone at Intel been able to reproduce it?
I just tried 4.12-rc7 at git b4df2e35. The frequency of modeset failures as increased to about 50% of the time. Sometimes the modeset fails on boot and I get a black screen. I have to ssh in to toggle modes until one sticks. I've had it fail setting the console mode before X starts. Any ideas on why these modesets are failing? This is a very frustrating bug that severely impacts usability.
Changing to High priority since the problem results on Black Screen / No Display sporadically (20-50%). Thanks.
Joseph, The logs shows that the driver thinks everything is ok. Have you tried this directly to the TV without the Denon receiver?
I can try it with the machine directly connected to the TV tonight. I previously had a machine with a Nvidia graphics card connected to the pulse-eight adapter and Denon and did not have this problem.
I can't reproduce this with the machine directly connected to a different input on the TV. I noticed if the screen stays black on a mode change when connected to the Denon and I toggle the input on the Denon between the PC and another input and back, video is restored. It must be an interaction with the Denon. I will contact their support. I don't understand why this was working with another machine with a Nvidia card.
It could simply be a timing difference with the speed of the frequency change. Now the question is can we actually do anything in the driver to help with this issue. Please update here if you get attention from Denon.
(In reply to Clinton Taylor from comment #11) > It could simply be a timing difference with the speed of the frequency > change. Now the question is can we actually do anything in the driver to > help with this issue. Please update here if you get attention from Denon. Hello, Changing to "NEEDINFO" while new information is added.
I have support ticket 170726-000441 open with Denon. Their reply suggested bypassing the receiver because of EDID issues: "It has been known that their has been EDID issues with computers and Denon Receivers since they do not constantly broadcast EDID. I would just bypass the receiver instead." It's not an EDID issue since I have the EDID fixed on the HDMI input through a kernel parameter. I also can't bypass the receiver since I don't have a spare HDMI inputs on the TV and HDMI-ARC doesn't support passthrough of HD audio codecs. I've followed up with them asking for more information about timing requirements for modesets.
Hello Joseph, any update with this issue? Also, if problem is being follow by Denon shouldn't we close this case?
Denon suggested a possible signaling issue at first. They suggested trying shorter cables, and using a the HDMI input port closest to the output on the receiver. I was already doing that, and I switched out a 10 ft cable for a 6 ft cable, and used cables rated for HDMI 2.0 bandwidth with no change. I noticed in the dmesg that the driver is setting a 12 bpc mode: [ 310.091302] [drm:intel_hdmi_compute_config [i915]] picking bpc to 12 for HDMI output [ 310.091333] [drm:intel_hdmi_compute_config [i915]] forcing pipe bpc to 36 for HDMI [ 310.091366] [drm:intel_atomic_check [i915]] hw max bpp: 36, pipe bpp: 36, dithering: 0 Denon suggested forcing a 10 bpc mode to see if it helps the issue. I noticed the problem is worse if I set a 3840x2160 @ 30 Hz mode and then toggle back to 1080p @ 60 Hz and 1080p @ 59.94 Hz. I'm only using 8 bpc in the X configuration. Is there a way for me to force 10 or 8 bpc on the physical mode?
The driver will always choose 12 bpc if the EDID advertises support. You can either modify the edid (panasonic-denon-edid.bin) to remove the 12 bpc support, or you can change the code in intel_hdmi.c so hdmi_12bpc_possible() returns false. 10 bpc is not supported on KBL.
I edited the EDID to disable 12-bit support. I don't have the issue if I'm toggling between 1920x1080 @ 60 Hz and 59.94 Hz at 8 bpc color. I still have the issue between 3840x2160 @ 30 Hz and 29.97 Hz at 8 bpc color. It seems to be an issue when the bandwidth is above a certain limit. It continues to happen if I set the Denon to passthrough and turn it into standby. Unfortunately, I don't have another AVR with HDMI to try.
On the Gigabyte GA-H270N-WIFI motherboard there are two chips on the top side of the board right in front of the HDMI connector tower. These are typically HDMI re-drivers, Can you get the make and model number off these chips?
They're Asmedia ASM1442K chips.
Out of curiousity, please attach /sys/kernel/debug/dri/0/i915_vbt
Created attachment 135188 [details] contents of /sys/kernel/debug/dri/0/i915_vbt Attached.
Here is a experimental patch that raises the HDMI voltage by ~200 mV. This may help with signal integrity across the 2 hdmi cables between the motherboard and the Denon if that is the issue. diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 0914ad9..cc1dfd7 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -460,7 +460,7 @@ static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv, enum port por if (IS_GEN9_BC(dev_priv)) { skl_get_buf_trans_hdmi(dev_priv, &n_hdmi_entries); - hdmi_default_entry = 8; + hdmi_default_entry = 9; } else if (IS_BROADWELL(dev_priv)) { n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi); hdmi_default_entry = 7;
I tried the patch, and I could still reproduce the issue. I don't really think it's signal degredation. Denon finally replied. They think it's an EDID negotiation issue between the TV and the HDMI repeater in Denon, and suggested I contact Panasonic for a firmware update. Since this is not a problem with other devices or the PC connected directly to the TV, and I can also get it to happen with a different 4K monitor attached to the Denon, I doubt Panasonic could fix this. It's probably a reclocking issue at high bandwidth on the HDMI repeater in the Denon, and I don't really have a workaround except buy a new receiver. I'm not sure Intel can to anything here, so feel free to close the bug.
I agree it's probably not a signal integrity issue. Closing as per request.
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.