DisplayPort AUX vs I2C-over-AUX Transactions

This article provides a direct comparison between native DisplayPort physical Auxiliary (AUX) channel transactions and I2C-over-AUX transactions. It explores how the bidirectional DisplayPort AUX channel manages both modern DisplayPort Configuration Data (DPCD) operations and backward-compatible I2C operations (such as EDID and MCCS), detailing the structural, operational, and functional differences between the two protocols.

The DisplayPort AUX Channel Overview

The DisplayPort Auxiliary (AUX) channel is a dedicated, bidirectional, half-duplex AC-coupled differential link operating alongside the main video lanes. Originally designed with a raw bit rate of 1 Mbps using Manchester-II encoding (and expanded up to 720 Mbps with 128b/132b encoding in DisplayPort 2.0+), it acts as the primary control bus between the video source (transmitter) and the display sink (receiver).

Every interaction over this bus occurs through request-and-reply packet transactions initiated exclusively by the source device. These transactions are broadly categorized into two types: Native AUX Transactions and I2C-over-AUX Transactions.

Native DisplayPort AUX Transactions

Native AUX transactions represent the standard, direct communication protocol engineered specifically for DisplayPort architectures.

Key Characteristics:

  • Primary Purpose: Used for low-level link configuration, link training, capability discovery, and ongoing link status monitoring.
  • Target Address Space: Accesses the DisplayPort Configuration Data (DPCD) registers located on the sink device. DPCD uses a 20-bit address space (ranging from 0x00000 to 0xFFFFF).
  • Command Types:
    • AUX Native Write (Command code 1000 in binary / 0x8)
    • AUX Native Read (Command code 1001 in binary / 0x9)
  • Payload Capacity: Each transaction can transfer between 1 and 16 bytes of data per burst.
  • Response Mechanism: The sink returns an immediate AUX reply containing status bits: ACK (success), NACK (negative acknowledgment), or DEFER (the receiver is busy and requests a retry).

Because native AUX operates directly with the sink's internal registers without bus translation, it features lower latency and minimal protocol overhead.

I2C-over-AUX Transactions

I2C-over-AUX is an emulation and tunneling protocol that allows standard I2C commands to be packaged and transmitted inside native AUX frames. DisplayPort does not include physical, dedicated I2C clock (SCL) and data (SDA) lines; instead, it encapsulates I2C traffic to maintain backward compatibility with legacy display identification standards.

Key Characteristics:

  • Primary Purpose: Primarily used to read Extended Display Identification Data (EDID) via the Display Data Channel (DDC), send Monitor Control Command Set (MCCS) data, or perform HDCP authentication on legacy downstream components.
  • Target Address Space: Targets 7-bit standard I2C slave addresses (e.g., 0x50 for EDID data). The 7-bit I2C address is mapped into the standard 20-bit AUX address field, with the unused upper bits set to zero.
  • Command Types:
    • I2C-over-AUX Write (Command code 0000 / 0x0)
    • I2C-over-AUX Read (Command code 0001 / 0x1)
    • I2C-over-AUX Write-Status-Update (Command code 0010 / 0x2)
  • Transaction Control (The MOT Bit): I2C requires START, REPEATED START, and STOP conditions. To emulate this on a packetized channel, I2C-over-AUX uses a Middle-of-Transaction (MOT) bit in the command header:
    • Setting MOT = 1 holds the virtual I2C bus open, allowing multi-burst reads or combined write-then-read operations without issuing an I2C STOP condition.
    • Setting MOT = 0 signals the end of the transaction, instructing the sink to issue an I2C STOP condition.
  • Response Mechanism: In addition to standard AUX reply codes (ACK, NACK, DEFER), the sink can return an I2C-NACK to signify that the virtual or bridged I2C slave device did not acknowledge the address or data byte.

Direct Comparison of Differences

Feature Native AUX Transactions I2C-over-AUX Transactions
Primary Role Read/write DPCD registers; link training and device control Read EDID, send MCCS commands, interact with I2C peripherals
Target Architecture Modern DisplayPort sinks and branch devices Legacy I2C slave devices (real or emulated)
Address Width 20-bit address space 7-bit I2C slave address (mapped into lower AUX address bits)
Protocol Flow Direct stateless register access Emulates stateful I2C bus conditions (START, STOP, ACK) using the MOT flag
Reply Codes Native ACK, NACK, DEFER Native replies plus virtual I2C-NACK and I2C-DEFER
Overhead Minimal; point-to-point packetization Higher; requires encapsulation, bus-holding states, and translation

Summary

Native AUX channel transactions provide direct, native access to DisplayPort's 20-bit DPCD register map for link setup and hardware control. In contrast, I2C-over-AUX is an encapsulation mechanism that simulates an I2C master-slave bus inside the AUX channel using the MOT bit, allowing DisplayPort sources to read EDID data and manage peripheral display features seamlessly without dedicated I2C pins.