Black Screen, No Signal, Flicker: An EDID and HDCP Checklist

Classify the symptom before touching anything

The symptom tells you which half of the handshake failed, and it is worth thirty seconds of observation before swapping a single cable.

Symptom	What it usually means
No signal at all, display reports no input	EDID not read, or no valid mode agreed — occasionally power or cable
Picture appears, drops for a second, comes back, repeatedly	HDCP renegotiation, or marginal cable at the chosen bit rate
Picture present but at the wrong resolution or refresh rate	EDID reported a different preferred mode than expected
Everything works except protected content, which is black	HDCP not completed across the full chain
Fine until a monitor or source was changed, then broken	EDID renegotiation triggered by the new device

The background on each mechanism is covered separately in What Is EDID? and What Is HDCP?. This page is about identifying which one you have.

The one test that isolates it: direct connection

Before changing configuration, connect the source straight to the display with a known-good short cable. This is the single most valuable step and the one most often skipped.

• Direct works, through-the-chain does not. The fault is in the chain: an extender, switch, splitter, KVM or converter is not passing or not completing the handshake.
• Direct does not work either. Stop investigating the chain. The problem is the source output mode, the display, or the cable — in that order of likelihood.
• Direct works at a lower resolution only. You have a bandwidth or cable-quality limit, not a handshake fault. Raise resolution step by step to find where it stops.

Write down what you observed. Half of these faults are intermittent, and "it worked when I tested it" is not a record anyone can act on later.

EDID faults: what changes and when

EDID is the display telling the source what it supports. The source picks a mode from that list, and every device in between has to agree with the result. The fault appears when the list changes after the system was commissioned, or when a device in the middle reports its own capabilities instead of passing the display's through.

Common triggers:

• A display is replaced. The new one reports a different preferred mode; the source switches to something the rest of the chain handles badly, typically at a higher pixel clock than the link can sustain.
• A switch or splitter is added. Some present their own EDID rather than the connected display's, so the source is negotiating against a device that is not the sink.
• A display is powered off. With multiple sinks, removing one can force renegotiation for all of them, which is why screens sometimes blink when a colleague switches off a monitor.
• An extender is introduced. Long-reach links, particularly over copper, have practical limits at higher pixel clocks; the 4K30 KVM 120 m extender, for instance, is rated 3840×2160@30Hz over pure-copper Category 6, and that rating assumes cable that genuinely meets the category.

The remedy in fixed installations is to stop the negotiation from happening: set the EDID explicitly, or fix the output mode on the source, so a later hardware swap cannot silently change the agreed mode.

HDCP faults: why only some content goes black

HDCP is content protection, and it is negotiated independently of the picture mode. That independence is what makes it diagnosable: if the picture works for a laptop desktop and goes black for a streaming service or a disc, the video path is fine and the HDCP chain is not.

Two properties cause most of the pain. First, HDCP has to be completed across every device in the chain, so one non-compliant element blackens the whole path even if everything else supports it. Second, the version in use is the lowest common denominator of the chain, so adding an older device can downgrade a working system.

Where an extender is involved, check what it supports rather than assuming. The ZY-CHK203 HDBaseT extender is specified with HDMI 1.4 and HDCP 1.4, which is the right question to ask of every device you add: not "does it do HDCP" but "which version, and does the source require more".

Where handshakes break in a real chain

Every device between source and display is a place the handshake can be renegotiated, passed through, or replaced. In descending order of how often they cause trouble:

1. Splitters and matrices that present their own EDID rather than the sink's.
2. Converters between interface types, where the protection and mode information has to be translated, not just the signal.
3. Extenders at the edge of their reach or on marginal cable.
4. KVM devices, which add a USB relationship to the video negotiation and can re-trigger it when the console changes.
5. Displays that were swapped in after commissioning, because nobody re-validated the agreed mode.

Reduce the chain where you can. A direct run that avoids two conversions is worth more than any configuration change you make to accommodate them.

Cable and power: the faults that are real

Having said most faults are handshakes, some genuinely are cable or power, and they have recognisable signatures.

• Sparkles or drop-outs that worsen with resolution. Cable at the edge of its bandwidth, or cable that does not meet the printed category. Copper-clad aluminium sold as Category 6 is the usual culprit; specify pure copper and say so in the bill of materials. See Twisted Pair Cable Basics.
• Intermittent faults that correlate with equipment switching on. Earthing or interference. Optical links remove the problem entirely because they are galvanically isolated — the reason ZY-OH1301 and similar fibre paths are chosen near large drives or traction power.
• A device that works on the bench and not in the rack. Power. Undersized supplies and shared adapters produce exactly this pattern, and it is worth checking before assuming anything about the signal.

Preventing it: lock the EDID, document the chain

Two habits remove most of these faults from a fixed installation. First, fix the EDID or the source output mode so that nothing downstream can renegotiate it. Second, record the chain as built — source, every intermediate device with its HDCP version, cable type and length, display model — because the fault will eventually arrive as "it used to work", and that sentence is only answerable with a record of what "used to" meant.

Checklist

Item	Pass criterion
Direct connection test	Source to display with a known-good short cable, result recorded
Agreed mode	Resolution and refresh rate read from the display, matching the design
Protected content	A known protected source plays through the full chain, not just a desktop
HDCP version	Lowest version in the chain identified and confirmed adequate for the source
EDID behaviour	Powering a display off does not disturb the remaining screens, or the behaviour is documented
Cable specification	Pure copper of the stated category, length within the device rating
Chain record	Every device, HDCP version and cable length written down at handover

Where to start

FAQ

Related reading

• What Is EDID? Why a Different Monitor Kills the Picture
• What Is HDCP? Why Protected Content Goes Black
• Twisted Pair Cable Basics for AV Installers
• KVM Extension: Fibre, HDBaseT or IP?