How Linux DRM Handles DisplayPort Connection Events

This article provides an overview of how the Linux kernel's Direct Rendering Manager (DRM) detects, processes, and responds to DisplayPort (DP) connection events. It details the journey from the initial physical connection and hardware interrupt to driver-level auxiliary channel communication, state updates within the Kernel Mode Setting (KMS) subsystem, and eventual notification dispatch to userspace display servers.

1. Hardware Detection and Hot Plug Detect (HPD)

The process begins at the physical layer when a DisplayPort cable is plugged into or unplugged from a display output. The monitor asserts the Hot Plug Detect (HPD) pin by driving the signal line high (typically 3.3V).

The Graphics Processing Unit (GPU) senses this voltage transition via dedicated HPD hardware pins and fires a hardware interrupt (IRQ) to the CPU. DisplayPort defines two primary types of HPD signals based on pulse duration:

  • Long Pulse (typically > 100ms): Signifies a genuine connection or disconnection event.
  • Short Pulse (typically 0.5ms – 1.0ms, or "HPD IRQ"): Indicates an attention request from an already connected sink, such as a loss of link synchronization, an HDCP event, or a Multi-Stream Transport (MST) topology change.

2. Driver-Level Interrupt Handling

When the CPU receives the HPD interrupt, the GPU vendor's DRM driver (such as i915, amdgpu, or nouveau) executes its Interrupt Service Routine (ISR).

Because reading display metadata involves latency-heavy input/output, the ISR does not process the event directly. Instead, it schedules an asynchronous work item on a kernel workqueue (often utilizing DRM helper libraries like drm_kms_helper) to handle the event outside the critical interrupt context.

3. DPCD Probing via the AUX Channel

The scheduled worker analyzes the event by communicating with the sink device over the DisplayPort Auxiliary (AUX) channel. The driver reads the DisplayPort Configuration Data (DPCD) registers located on the monitor:

  • For a short pulse, the driver inspects specific DPCD interrupt status registers (such as DPCD 0x0200 to 0x0205) to determine if link training must be renegotiated or if an MST message is pending.
  • For a long pulse, the driver verifies whether a sink is present. If detected, it reads the DPCD receiver capabilities to establish supported link rates, lane counts, and whether the device supports DisplayPort Multi-Stream Transport (DP-MST).

4. EDID Read and DRM Connector State Updates

If a valid connection is confirmed, the driver retrieves the Extended Display Identification Data (EDID) from the display using I2C-over-AUX.

The driver passes the raw EDID to the DRM core. DRM validates the checksum and parses the EDID to construct a list of supported display modes (resolutions, refresh rates, and color formats). The DRM subsystem then updates the internal state of the corresponding drm_connector object, toggling its status to DRM_MODE_CONNECTED or DRM_MODE_DISCONNECTED.

If the device supports MST, the kernel’s DP-MST helper library takes over branch and port management, dynamically creating or destroying virtual drm_connector instances for daisy-chained or hub-connected displays.

5. Userspace Notification

Once the DRM core updates its internal connector states and mode lists, it informs userspace compositors of the hardware change. The driver calls drm_kms_helper_hotplug_event(), which sends a uevent across the Netlink socket with the HOTPLUG=1 environment variable.

Display servers and compositors (such as Wayland compositors or Xorg) listen for these uevents via udev. Upon receipt, the compositor queries the DRM subsystem via ioctl interfaces (such as DRM_IOCTL_MODE_GETCONNECTOR) to read the updated topology and execute Atomic KMS requests to configure the new displays.