Bug 100885 - [SNB] Blank screen after cycling HDMI receiver input
Summary: [SNB] Blank screen after cycling HDMI receiver input
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: high normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-29 18:34 UTC by Matt Horan
Modified: 2019-06-18 14:37 UTC (History)
2 users (show)

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


Attachments
dmesg from first boot and after HDMI cycle (107.02 KB, text/plain)
2017-04-29 18:34 UTC, Matt Horan
no flags Details
edid from receiver (256 bytes, application/octet-stream)
2017-04-29 18:34 UTC, Matt Horan
no flags Details
dmesg from first boot and after input cycle w/ 4.13-rc6 (116.58 KB, text/plain)
2017-08-25 00:57 UTC, Matt Horan
no flags Details
dmesg from drm-tip as of September 8, 2018 (870.15 KB, text/x-log)
2018-09-09 00:53 UTC, Matt Horan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Horan 2017-04-29 18:34:32 UTC
Created attachment 131151 [details]
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.
Comment 1 Matt Horan 2017-04-29 18:34:59 UTC
Created attachment 131152 [details]
edid from receiver
Comment 2 Matt Horan 2017-04-29 18:40:39 UTC
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?
Comment 3 Elizabeth 2017-07-20 20:57:28 UTC
(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.
Comment 4 Matt Horan 2017-07-21 01:40:20 UTC
(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.
Comment 5 Elizabeth 2017-08-24 20:41:32 UTC
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
Comment 6 Matt Horan 2017-08-25 00:57:02 UTC
Created attachment 133764 [details]
dmesg from first boot and after input cycle w/ 4.13-rc6

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.
Comment 7 Matt Horan 2018-02-01 03:49:28 UTC
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.
Comment 8 Jani Saarinen 2018-03-29 07:11:45 UTC
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.
Comment 9 Jani Saarinen 2018-04-23 09:53:31 UTC
Closing, please re-open if still occurs.
Comment 10 Matt Horan 2018-04-23 11:04:17 UTC
This issue still exists.
Comment 11 Jani Saarinen 2018-04-23 12:15:02 UTC
Ville, any help here?
Comment 12 Lakshmi 2018-09-08 22:52:03 UTC
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.
Comment 13 Matt Horan 2018-09-09 00:53:13 UTC
Created attachment 141492 [details]
dmesg from drm-tip as of September 8, 2018

The issue persists with the latest drm-tip (6dc8457a2f2093eecb9c6cbb7306fd25bb1664e6). dmesg attached.
Comment 14 Lakshmi 2018-10-18 15:15:35 UTC
Ville, any help here?
Comment 15 Ville Syrjala 2018-10-18 16:04:43 UTC
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.
Comment 16 Matt Horan 2018-10-18 16:16:01 UTC
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.
Comment 17 Ville Syrjala 2019-01-22 18:09:29 UTC
We now have the properly to limite the bpc.

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

Does that help?
Comment 18 Matt Horan 2019-01-23 03:50:46 UTC
(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.
Comment 19 Matt Horan 2019-04-02 14:40:23 UTC
(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.
Comment 20 James Ausmus 2019-06-18 14:37:14 UTC
Can you retest with drm-tip? There have been some changes around the max_bpc handling that may impact your situation


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.