Sorry, you need to enable JavaScript to visit this website.

Primary tabs

HDMI handshake issue

2 posts / 0 new
01 Staff's picture
01 Staff (not verified)

Aug 17, 2013 - 06:57am

  • 01 Staff's picture
    01 Staff (not verified)

    Yet another issue with my new Haswell-based HTPC setup. This time it occurs whenever I've left my Onkyo AVR in standby for a while and resumes: Either the picture seen on the screen is malformed (wrong resolution, cropped) or it doesn't show any picture all, forcing me to hard-power off the HTPC, potentially causing data loss. I suspect it has to do with HDCP handshaking and that it's not properly re-initialized when the AVR resumes. I don't know if the problem is with HTPC or the AVR, but either way it's really irritating when a totally useless DRM tech once again does nothing but cause trouble.

    Two questions:

    1. How is HDCP handshaking handled when the receiving device resumes from standby? Does it properly listen for new handshakes or does it just "assume" the link is okay since last boot? (I don't really know how this works, please just tell me that this is a scenario that you have thought of)

    2. Is there any workaround for this problem other than leaving the AVR on all the time? (I want the HTPC to remain on since it doubles as a storage server)

    I could attach the HTPC directly to the TV to see if the problem persists and thus ruling out the receiver, but unfortunately I don't have a HDMI cable that is long enough.


    Aug 17, 2013 - 06:57am
  • jadedcyborg's picture
    jadedcyborg (not verified)

    Okey, I got some more troubleshooting info on this issue:

    1. It's somehow related to HDMI CEC. If I turn of HDMI Control in the reciever, the bug doesn't occur. Which is strange, because I didn't think the Haswell even supported CEC. When I power on the AVR after 8+ hours of standby, the picture returns as expected.

    2. It's not HDCP releated. HDCP is always on, thus the problem wouldn't go away as described in (1).

    2. The problem is definitely on the HTPC-side. I did the following steps:

    a. Use the HTPC as usual. Picture and sound is fine.
    b. Turn of the TV and AVR (standby), leave the HTPC on.
    c. Sleep for 8+ hours.
    d. ssh into the HTPC. HTPC responds and operates as excpeted via ssh.
    e. Turn on the TV and AVR. At this precise moment, the HTPC stops responding to anything via ssh and the TV screen is blue (no signal). It seems the HTPC has hung the moment the AVR was turned on.

    Thus I conclude there is a problem with the video drivers and/or kernel. Regardless of what the AVR does or sends over HDMI, there is no scenrio that should result in the system hanging.

    Also, whatever component that is causing the issue, it doesn't affect the system at the cryptsetup prompt. Once I accidently restarted the system instead of powering it off, and when I came back the morning after the system was still on and waiting at the cryptsetup unlock screen (since my system uses FDE). I turned on the TV and AVR and the pictured returned as expected. I'm no Linux expert, but I think only the kernel is loaded at that point, with xorg, video drivers etc loading after the system is unencrypted. Thus, the problem probably lies withing xorg/video drivers rather than the kernel.

    It would be nice to hear something from Intel devs on this issue.

    Aug 26, 2013 - 02:00am
  • Hi,

    We are aware of suspend/resume issues and have devs working on it. No workaround so far.

    Anyways it would be good if you could file a bug at:



    Aug 26, 2013 - 01:14pm
  • Topic locked