HDMI DDC Slave Addresses and Protocol Flows

HDMI DDC (Display Data Channel) is based on I2C: the source (Source/TX) acts as master, while the display or repeater acts as slave. In addition to EDID, the same SCL/SDA pair carries HDCP, SCDC, and optional DDC/CI traffic.

This article follows address overview → EDID → HDCP → SCDC → DDC/CI for quick reference during trace capture, firmware debugging, and IP integration. Capabilities vary across specification revisions and device IP, so verify implementation details against the target specification and device documentation.

1. DDC slave address summary

DDC addresses appear in two common forms: 8-bit frame addresses (including the R/W bit, e.g. 0xA0) and 7-bit slave addresses (common in Linux drivers and i2cdetect, e.g. 0x50). The table below lists both.

Function	7-bit address	8-bit W / R	Access	Standard / notes
E-EDID	0x50	0xA0 / 0xA1	Source read-only	E-DDC; 128-byte blocks starting at block 0
E-DDC segment pointer	0x30	0x60 / —	Write-only	Selects EDID space above 256 bytes
HDCP	0x3A	0x74 / 0x75	R/W	HDCP 1.4 and HDCP 2.x share the address; register maps differ
SCDC	0x54	0xA8 / 0xA9	Bidirectional	HDMI 2.0+; HDMI 2.1 FRL training extends the same address space
DDC/CI	0x37	0x6E / 0x6F	Bidirectional	Optional VESA display-control channel

Usage notes:

• Valid HPD and working DDC pull-ups are normally required before accessing EDID, SCDC, or HDCP.
• HDCP 1.4 and HDCP 2.x use different register maps. Before using HDCP 2.x, check the support bit in HDCP2Version.
• SCDC is accessible only when SCDC_Present = 1 in the Sink EDID HF-VSDB; FRL capability is declared separately via fields such as Max_FRL_Rate.
• DDC/CI is optional. A display may not support it, may disable it by default, or may not expose it through a repeater.

---

2. EDID read

2.1 Data layout and capacity

• Each EDID block is fixed at 128 bytes.
• Byte 126 of block 0 is the extension block count N; total length is (N + 1) × 128 bytes. Do not assume N ≤ 3; choose a read limit based on implementation capacity and data validity.
• Byte 127 of block 0 and byte 127 of each extension block are 128-byte additive checksums (sum mod 256 equals 0).
• The first 8 bytes of block 0 are fixed: 00 FF FF FF FF FF FF 00.

Common HD-related extension block types:

Extension type	Tag (byte 0)	Role
CEA-861 extension	0x02	Video/audio formats, HDMI VSDB, HDR, etc.
HF-VSDB	Inside CEA block	SCDC_Present, Max_FRL_Rate, ALLM/VRR, and other 2.0/2.1 capabilities

2.2 Basic read flow (≤256 bytes)

1. I2C write to slave 0x50 with start offset 0x00 (sets the internal address pointer).
2. I2C read from slave 0x50 to fetch one 128-byte block.
3. Use the extension count to read further blocks, validating each block checksum.

2.3 E-DDC extended read (>256 bytes)

When N ≥ 2 (total length ≥ 384 bytes), use the segment pointer:

For block number B, the segment is floor(B / 2); the offset is 0x00 for an even block and 0x80 for an odd block:

1. Write the segment number to 0x30; each segment covers two EDID blocks.
2. Write offset 0x00 or 0x80 to 0x50.
3. Read 128 bytes from 0x50.
4. Repeat until all required extension blocks are read.

The segment pointer is separate state. Do not assume that STOP resets it to zero; ensure the correct segment is selected before reading the base segment.

2.4 Debug tips

• After hot-plug, wait for HPD to stabilize before reading; some Sinks need several milliseconds after the HPD rising edge before DDC responds.
• EDID and SCDC are separate: EDID is read-only for the source; do not use 0x50 to modify SCDC registers.
• Use the site EDID decode tool and linuxhw EDID data to interpret field meanings.

---

3. HDCP interaction and key registers

The HDCP port is fixed at 0x3A (8-bit 0x74/0x75). HDCP 1.4 and HDCP 2.2/2.3 share the physical address; an HDCP 2.2 receiver advertises support through bit2 of HDCP2Version (offset 0x50). The selected authentication version also depends on Source and Sink capabilities and the content-protection policy.

3.1 HDCP 1.4 (DDC register map)

Authentication is initiated by the Transmitter (source). Typical three phases: exchange KSV → compute Ri/Ri' → enable encryption.

Offset	Name	Dir	Length	Description
0x00	Bksv	R	5 B	Receiver Key Selection Vector
0x08	Ri'	R	2 B	Link integrity check value
0x0A	Pj'	R	1 B	Enhanced link verification value
0x10	Aksv	W	5 B	Transmitter KSV
0x18	An	W	8 B	Session random number
0x20	V'	R	20 B	Repeater topology verification value
0x40	Bcaps	R	1 B	Receiver capabilities and Repeater flag
0x41	Bstatus	R	2 B	Repeater topology status
0x43	KSV FIFO	R	Variable	Downstream KSV list

Interaction notes:

• After the source writes Aksv and An, it reads Bksv; both sides compute Km locally, then derive Ks for video encryption.
• Compare Ri/Ri' according to the timing defined by the specification.
• Bcaps.REPEATER and Bstatus drive Repeater handling; a repeater must also read the KSV FIFO and verify V'.

3.2 HDCP 2.2 / 2.3 (message-based protocol)

HDCP 2.x no longer uses the HDCP 1.4 KSV/Ri register layout. Instead, Write_Message / Read_Message exchange structured messages such as AKE, LC, and SKE (RSA/AES session). Key DDC registers:

Offset	Name	Dir	Description
0x50	HDCP2Version	R	bit2 = 1 indicates HDCP 2.2 support over HDMI
0x60	Write_Message	W	Burst-write a message to the receiver
0x70	RxStatus	R	2 B, status and pending message length
0x80	Read_Message	R	Burst-read a message from the receiver

Common RxStatus fields (conceptual):

Field	Meaning
READY	Receiver has a message to read via Read_Message
REAUTH_REQ	Re-authentication requested
Message_Size	Current message byte count (parse per spec bit fields)

Typical flow (source perspective):

1. Read HDCP2Version and check its support bit.
2. Send AKE_Init and subsequent messages through Write_Message; poll RxStatus until READY.
3. Read AKE_Send_Cert and subsequent responses through Read_Message; RxCaps is carried in the certificate response.
4. After LC_Init / LC_Send_L1 and SKE_Send_Eks, enter encrypted state.
5. Handle RxStatus.REAUTH_REQ, hot-plug events, and Repeater topology changes as required by the specification.

HDCP 1.4 vs 2.2/2.3 summary:

Item	HDCP 1.4	HDCP 2.2/2.3
Auth model	KSV + An + Ri	Certificates + key-exchange messages
DDC usage	Fixed-offset read/write	Message length + burst read/write
4K content	Limited in some cases	Commercial 4K typically requires 2.2+
Compatibility	Widely supported on legacy devices	Requires 2.x on both TX and RX

---

4. SCDC interaction and key registers

SCDC (Status and Control Data Channel) was introduced with HDMI 2.0 at I2C address 0x54 (0xA8/0xA9). Unlike EDID, SCDC carries bidirectional status and control information. Individual registers and fields are updated by either the Source or Sink for TMDS scrambling, clock ratio, link status, and HDMI 2.1 FRL training.

Access prerequisite: SCDC_Present = 1 in the Sink EDID HF-VSDB; otherwise the source must not access SCDC.

4.1 General registers (TMDS / HDMI 2.0)

Offset	Name	R/W	Description
0x01	Sink Version	R	SCDC version supported by the Sink
0x02	Source Version	W	SCDC version used by the Source
0x10	Update_0	R/W	Update flags, low byte
0x11	Update_1	R/W	Update flags, high byte
0x20	TMDS Configuration	R/W	Scrambling_Enable, TMDS_Bit_Clock_Ratio
0x21	Scrambler Status	R	Scrambler status
0x30	Config_0	W	Source configuration such as RR_Enable
0x31	Config_1	W	FRL_Rate and FFE_Levels (HDMI 2.1)
0x35	Source Test Configuration	R	Source test settings requested by the Sink
0x40	Status Flags_0	R	Clock/lane lock and FLT_Ready
0x41–0x42	Status Flags_1/2	R	FRL link-training-pattern requests
0x50–0x57	CED / RS counters	R	Character or Reed-Solomon error counts

TMDS Configuration (0x20) notes:

• TMDS_Bit_Clock_Ratio = 0: TMDS clock/data ratio 1:10 for TMDS character rates up to 340 Mcsc.
• TMDS_Bit_Clock_Ratio = 1: ratio 1:40 for TMDS character rates above 340 Mcsc.
• Configure scrambling and the clock ratio together according to the current TMDS character rate and Sink capability; follow the target HDMI revision for switching order and timing.

Update Flags: Update_0/1 are primarily set by the Sink to notify the Source of status, CED, or FRL-training changes. The Source clears a handled flag by writing 1 to it.

4.2 FRL-related registers (HDMI 2.1)

In FRL (Fixed Rate Link) mode, link training is coordinated via SCDC and Max_FRL_Rate in EDID. Main extension registers (same 0x54 address space):

Offset	Key fields	Purpose
0x10	FLT_Update, FRL_Start	Sink signals updated training state or successful FRL start
0x31	FRL_Rate, FFE_Levels	Source selects the FRL rate and current FFE level
0x35	FLT_no_timeout, etc.	Source test configuration requested by the Sink; not for casual use in normal operation
0x40	FLT_Ready, Lane Locked	Sink readiness and lane-lock status
0x41–0x42	LTP request	Sink requests the next training pattern for each lane

FRL bring-up overview:

1. Read EDID: SCDC_Present=1 in HF-VSDB; record Max_FRL_Rate.
2. Write Source Version, then select an FRL_Rate in Config_1 that does not exceed the EDID declaration.
3. Enter the Link Training state machine (LTS1–LTS4), advancing according to FLT_Update, FLT_Ready, and per-lane LTP requests.
4. On training failure or timeout, fall back to TMDS mode.
5. Before formal output, confirm FRL_Rate matches lane count (3 lane / 4 lane).

FRL and TMDS are mutually exclusive: after entering FRL, the TMDS Configuration scrambling path no longer applies; distinguish the current link mode in trace captures.

---

5. DDC/CI interaction

DDC/CI (Display Data Channel Command Interface) is a VESA bidirectional command channel at I2C slave address 0x37 (0x6E/0x6F). The host reads and writes brightness, contrast, input select, and other parameters via VCP (Virtual Control Panel) codes in MCCS (Monitor Control Command Set). On HDMI cables, DDC/CI shares SCL/SDA with EDID but uses a separate logical address.

5.1 Message format

DDC/CI transfers framed structures on I2C, not plain linear ROM reads like EDID:

Field	Description
Source address	Host requests normally use 0x51
Length	Length byte with high bit set
Payload	VCP code + parameters
Checksum	XOR checksum over the entire frame

Timing: After the host sends a request, wait for the Sink to process (spec recommends ≥40 ms) before reading the response; commands sent too close together may return invalid data.

5.2 Common VCP examples

VCP code	Function	Notes
0x10	Luminance	Brightness (0–100 or device-defined range)
0x12	Contrast	Contrast
0x60	Input Select	Input switching (enumeration varies by vendor)
0xD6	Power Mode	Power / standby state
0xC0	Display Usage Time	Accumulated usage time (read-only)

Read VCP: GET VCP Feature; write VCP: SET VCP Feature. On Linux, use ddcutil on /dev/i2c-* for debugging (requires 0x37 ACK and DDC/CI enabled in the display OSD).

5.3 Implementation notes

• Shared with EDID: Serialize DDC transactions in firmware and avoid holding the bus long enough to block EDID or HDCP traffic.
• Optional: Sinks without DDC/CI will NACK at 0x37; this is normal.
• Repeater / matrix: Some repeaters pass through EDID and HDCP only, not DDC/CI.

---

Related tools

• EDID decode
• MS2130 / MS2130S EDID helper
• linuxhw EDID data browser

Summary

Common HDMI DDC slave addresses include: EDID (0x50), segment pointer (0x30), HDCP (0x3A), SCDC (0x54), and DDC/CI (0x37). Typical bring-up order: HPD → read EDID → configure the link and output video → authenticate HDCP for protected content; FRL scenarios complete Link Training over SCDC; display management uses DDC/CI. When capturing traces or porting drivers, confirm the 7-bit address and current HDCP version first to avoid wasted debug effort.