[SNB] Blank screen after cycling HDMI receiver input

Submitted by Matthew Horan @mhoran

Assigned to Intel GFX Bugs mailing list

Link to original bug (#100885)

Description

Created attachment 131151
dmesg from first boot and after HDMI cycle

Since upgrading to a new HDMI receiver, I've been encountering an issue with my Intel Graphics based systems. On first boot, HDMI output displays fine through the receiver and on the TV. However, after cycling to another HDMI input on the receiver and then back to the PC, the screen remains blank.

There may be a deeper issue here, as I see this before KMS has been initialized, e.g. in the BIOS menu. However, I'm hoping there's something that can be done to address the issue.

The EDID detected by the system is identical both before and after the cycle. I've attached the EDID and a dmesg with debugging, which shows the messages on first boot and then after cycling the input.

I've been able to reproduce this on multiple Intel Graphics based systems connected to the same HDMI input.

Note that there is a forum discussion on the manufacturer's website that discusses this specific issue as well: http://emotivalounge.proboards.com/thread/38824/xmc-pc-hdmi-handshake-problem

Any help would be much appreciated.

Attachment 131151, "dmesg from first boot and after HDMI cycle":
dmesg

added Community feature: display/HDMI platform: SNB priority::medium severity::normal + 1 deleted label

Matthew Horan @mhoran uploaded an attachment:

Attachment 131152, "edid from receiver":
edid

Matthew Horan @mhoran said:

The only way to resolve the issue is to completely disconnect the HDMI cable, and then reconnect. So perhaps there's a quirk that could be utilized to simulate this effect?

Elizabeth said:

(In reply to Matt Horan from comment 2)

The only way to resolve the issue is to completely disconnect the HDMI
cable, and then reconnect. So perhaps there's a quirk that could be utilized
to simulate this effect?
Hello Matt,
Is this still valid? Could you try to reproduce with 4.12 or 4.13 https://www.kernel.org/.
Thank you.

Matthew Horan @mhoran said:

(In reply to Elizabeth from comment 3)

Is this still valid? Could you try to reproduce with 4.12 or 4.13

Yes; still seeing this with 4.12.2 compiled this evening.

Elizabeth said:

Hello Matt,
How are you connecting your PC to the receiver? Could you attach fresh dmesg with latest kernel version?

From dmesg last lines:
[ 106.035590] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions
[ 106.035619] [drm:i915_hotplug_work_func [i915]] Connector HDMI-A-2 (pin 7) received hotplug event.
[ 106.035644] [drm:intel_hdmi_detect [i915]] [CONNECTOR:42:HDMI-A-2]
[ 106.061028] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpd] NAK for addr: 0040 w(1)
[ 106.061042] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpd] NAK on first message, retry
[ 106.061204] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpd] NAK for addr: 0040 w(1)
[ 106.061213] [drm:drm_rgb_quant_range_selectable [drm]] CEA VCDB 0xfb
[ 106.061219] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support
[ 106.061233] [drm:i915_hotplug_work_func [i915]] Connector DP-2 (pin 7) received hotplug event.
[ 106.061245] [drm:intel_dp_detect [i915]] [CONNECTOR:44:DP-2]
[ 106.063706] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.066162] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.068618] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.071072] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.073525] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.075979] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.078433] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.080886] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.083339] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.085791] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.088247] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.090700] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.093152] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.095605] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.098057] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.100511] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.102969] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.105421] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.107875] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.110328] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.112782] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.115235] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.117687] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.120142] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.122595] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.125046] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.127500] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.129951] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.132406] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.134858] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.137311] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.139765] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[ 106.139772] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110

Matthew Horan @mhoran uploaded an attachment:

Attached is a dmesg from first boot through an input cycle on my receiver to another device (Xbox 360) and back to the PC. While the signal works fine on first boot, after cycling to another HDMI device and back, the TV input is completely blank (no sync error or anything -- just blank.)

The computer is connected via HDMI to the Emotiva XMC-1 receiver. The receiver is then connected via HDMI to my Sony TV.

When connected directly to the TV, the computer is fine. The computer has worked fine (though with other caveats) with other HDMI receivers. The XMC-1 unit seems to be a bit finicky -- others on the user forum have reported similar issues. However, given that the issue can be resolved by unplugging and then reconnecting the HDMI cable from the computer, I'm hopeful for a software fix.

Attachment 133764, "dmesg from first boot and after input cycle w/ 4.13-rc6":
dmesg

Matthew Horan @mhoran said:

I used to be able to reproduce this issue regularly with my laptop (i7-5600U, Intel(R) HD Graphics 5500). However, this occurs far less often running kernel 4.14. When the issue does occur, I can toggle the display off and back on from X and it goes away.

However, my media center (i5-2500K, Intel(R) HD Graphics 3000) still cannot recover from this issue. I'd prefer to not buy new hardware if this can be resolved in software, but I realize my system is quite old at this point.

For what it's worth, I managed to find a Windows machine (i7-4600U, Intel HD Graphics 4400) and could not reproduce this issue. Unlike the Linux machine running i7-5600U/HD Graphics 5500, I never found that the screen would remain blank. Note that the TV detects "12bpp" when connected to my Linux machines but not Windows.

Jani Saarinen @jani.saarinen said:

First of all. Sorry about spam.
This is mass update for our bugs.

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

Jani Saarinen @jani.saarinen said:

Closing, please re-open if still occurs.

Matthew Horan @mhoran said:

This issue still exists.

Jani Saarinen @jani.saarinen said:

Ville, any help here?

LAKSHMINARAYANA VUDUM @l4kshmi said:

Sorry for the delay...

Matt, Do you still see the issue with latest drm-tip?
(https://cgit.freedesktop.org/drm-tip)
If problem persists attach the latest full dmesg from boot with ernel parameters drm.debug=0x1e log_buf_len=4M.

This will speed up the investigation.

Matthew Horan @mhoran uploaded an attachment:

The issue persists with the latest drm-tip (6dc8457a2f2093eecb9c6cbb7306fd25bb1664e6). dmesg attached.

Attachment 141492, "dmesg from drm-tip as of September 8, 2018":
dmesg.log

LAKSHMINARAYANA VUDUM @l4kshmi said:

Ville, any help here?

Ville Syrjälä @vsyrjala said:

Sounds like a crappy receiver to me. As a workaround for various 12bpc issues we're going to add the new connector property that allows forcing 8bpc instead. I'm expecting it to land soonish.

Matthew Horan @mhoran said:

I don't believe forcing 8bpc will resolve the issue. I had edited the EDID of the receiver to disable 12bpc and set that using the kernel cmdline (for a previous receiver workaround) and still experienced this issue.

Also, 12bpc works just fine with other devices, this receiver, and my TV. This is only an issue with the PC.

This is a high end receiver, and while I don't doubt there could be issues in their implementation of the spec in some way, somehow other devices work just fine.

Ville Syrjälä @vsyrjala said:

We now have the properly to limite the bpc.

xrandr --output <whatever> --set 'max bpc' 8

Does that help?

Matthew Horan @mhoran said:

(In reply to Ville Syrjala from comment 17)

We now have the properly to limite the bpc.

xrandr --output <whatever> --set 'max bpc' 8

Does that help?

Does this require a specific kernel version and/or xrandr version? Happy to give it a shot.

However, I do know that when hooked up directly to the display, 12bpc is just fine, and other 12bpc sources work through the receiver without issue.

In fact, another system with Intel integrated graphics running Windows does *not* exhibit this behavior, while my media center does.

Matthew Horan @mhoran said:

(In reply to Matt Horan from comment 18)

(In reply to Ville Syrjala from comment 17)

We now have the properly to limite the bpc.

xrandr --output <whatever> --set 'max bpc' 8

Does that help?

Does this require a specific kernel version and/or xrandr version? Happy to
give it a shot.

I discovered that all that is needed is a kernel that supports the 'max bpc' prop, so I installed kernel 5.0.2. I successfully set max bpc to 8 when the display was working. However, when switching to another input and then back, the screen was blank. I could no longer set max bpc. xrandr --props showed max bpc of 12. If I tried to set max bpc to 8, the setting was seemingly ignored, and the screen remained blank.

I also tested with a newer Haswell machine, running both Windows and Linux. On Windows, I could not reproduce the issue. On Linux, I could not reproduce the issue as reliably, but it did occur. Interestingly, switching inputs a second time would resolve the issue. This is not a viable solution, however, as I do not plan to replace my SNB system any time soon (and something still seems broken.)

The only difference I noticed between Windows and Linux is that Windows never switched the display to 12bpc. I could not find an option in Windows to cause this to happen.