DDC/CI Protocol and DisplayPort AUX Tunneling Explained

The Display Data Channel/Command Interface (DDC/CI) is a standard protocol that allows a computer to send control commands directly to a connected monitor, enabling software-based adjustments of settings such as brightness, contrast, and color balance. While traditionally transmitted over dedicated physical I2C wiring found in legacy connections like VGA and DVI, modern interfaces like DisplayPort lack these dedicated lines. Instead, DisplayPort transports DDC/CI traffic by encapsulating standard I2C transactions into packets sent over its bidirectional Auxiliary (AUX) channel—a process known as I2C-over-AUX tunneling.

What Is the DDC/CI Protocol?

DDC/CI is a bidirectional communications standard defined by the Video Electronics Standards Association (VESA). It serves as an expansion of the basic DDC standard, which was originally designed solely to transmit Extended Display Identification Data (EDID) from the monitor to the host graphics card.

With DDC/CI, the communication becomes two-way using the Monitor Control Command Set (MCCS). The host can query the monitor's capabilities and current settings, as well as transmit write commands to adjust parameters:

  • Display adjustments (brightness, contrast, color temperature, tint)
  • Geometry adjustments (horizontal/vertical position, phase, clock)
  • Hardware control (input source switching, audio volume, power state management)

Electrically, DDC/CI was designed to run over the simple two-wire I2C serial bus (consisting of Serial Clock [SCL] and Serial Data [SDA] lines) operating at the standard 7-bit device address 0x37.

The DisplayPort Auxiliary (AUX) Channel

DisplayPort does not use dedicated physical pins for I2C communication. Instead, it relies on a packet-based architecture consisting of high-speed Main Link lanes for video and audio, and a dedicated, bidirectional, half-duplex sideband connection known as the Auxiliary (AUX) Channel.

The standard DP AUX channel operates over an AC-coupled differential pair running at 1 Mbps with Manchester II encoding (extended to 720 Mbps with 8b/10b encoding in newer versions as "Fast AUX"). The AUX channel handles link configuration, link training, device status reporting via DPCD (DisplayPort Configuration Data), and legacy display management traffic.

How DDC/CI Is Tunneled Through the AUX Channel

To retain compatibility with standard monitor control software without adding dedicated I2C pins, VESA specified an I2C-over-AUX translation mechanism within the DisplayPort standard. This allows the host's graphics driver to wrap standard DDC/CI I2C commands into DisplayPort AUX request packets.

The tunneling process occurs through the following steps:

1. Packet Encapsulation (I2C-over-AUX Syntax)

The host GPU constructs a standard DP AUX request packet. Within the 4-bit command field of the AUX header, the host specifies an I2C transaction rather than a native DPCD transaction. The primary command types include:

  • I2C-Write: Transmits data to an I2C slave.
  • I2C-Read: Requests data from an I2C slave.
  • I2C-Write-Status-Update: Monitors write status without sending new data.

The AUX packet also includes the 20-bit address field (which houses the standard 7-bit DDC/CI I2C address 0x37), a length counter, and the data payload containing the MCCS command bytes.

2. Transmission Across the Cable

The encapsulated packet is serialized and sent across the physical AUX channel differential pair to the display's receiver hardware.

3. Monitor Demultiplexing and Execution

The display’s DisplayPort receiver (sink) decodes the incoming AUX packet. Upon recognizing the command as an I2C-over-AUX transaction, it routes the payload to the display scalar or internal microcontroller:

  • Integrated Implementations: The display controller directly interprets the payload and executes the MCCS command internally.
  • Bridged Implementations: In displays with discrete bridge chips, the chip regenerates physical I2C clock (SCL) and data (SDA) signals and routes them to an internal hardware I2C bus linked to the monitor's scalar.

4. Sink Response Handling

The display responds back to the host across the AUX channel using standard AUX reply codes:

  • AUX ACK: The monitor successfully accepted the transaction.
  • AUX NACK: The addressed device failed to acknowledge (e.g., DDC/CI is disabled in the monitor’s on-screen menu).
  • AUX DEFER: The monitor is temporarily busy processing an internal operation and instructs the host to retry the request.

If the command was an MCCS read request, the reply packet also carries the requested data payload (such as the current brightness value) back to the host.

Through this tunneling technique, operating systems and monitor utilities can continue interacting with DDC/CI software layers identically to how they would over native I2C, while running entirely on the packetized physical layer of DisplayPort.