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.
Created attachment 131152 [details] edid from receiver
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?
(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.
(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.
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
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.
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.
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.
Closing, please re-open if still occurs.
This issue still exists.
Ville, any help here?
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.
Created attachment 141492 [details] dmesg from drm-tip as of September 8, 2018 The issue persists with the latest drm-tip (6dc8457a2f2093eecb9c6cbb7306fd25bb1664e6). dmesg attached.
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.
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.
We now have the properly to limite the bpc. xrandr --output <whatever> --set 'max bpc' 8 Does that help?
(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.
(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.
Can you retest with drm-tip? There have been some changes around the max_bpc handling that may impact your situation
(In reply to Matt Horan from comment #19) > (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. (In reply to James Ausmus from comment #20) > Can you retest with drm-tip? There have been some changes around the max_bpc > handling that may impact your situation No feedback from more than a month. Dropping the Priority to Medium. Matt, Can you please provide your feedback after verifying the issue drm-tip (https://cgit.freedesktop.org/drm-tip) ?
The issue is still not resolved with the latest drm-tip. The good news is that setting the 'max bpc' property now seems to stick; however, switching from the SNB machine to another HDMI device (Roku) and back again results in a black screen that I can only recover from by either rebooting or disconnecting and reconnecting the HDMI cable.
(In reply to Matt Horan from comment #22) > The issue is still not resolved with the latest drm-tip. The good news is > that setting the 'max bpc' property now seems to stick; however, switching > from the SNB machine to another HDMI device (Roku) and back again results in > a black screen that I can only recover from by either rebooting or > disconnecting and reconnecting the HDMI cable. Can you please attach the dmesg from boot for this case?
Created attachment 144848 [details] dmesg from drm-tip as of July 21, 2019 dmesg attached. This is after running `xrandr --output HDMI-2 --set 'max bpc' 8`. Note that running this xrandr command causes the screen to go blank and never recover.
(In reply to Matt Horan from comment #22) > The issue is still not resolved with the latest drm-tip. The good news is > that setting the 'max bpc' property now seems to stick; however, switching > from the SNB machine to another HDMI device (Roku) and back again results in > a black screen that I can only recover from by either rebooting or > disconnecting and reconnecting the HDMI cable. @James, any further suggestion.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/35.
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.