A Journey through Upstream Atomic KMS to Achieve DP Compliance

### Overview In this talk, Nancy Navarre, a graphics kernel developer at Intel, recounts her journey from being a graphics newcomer to implementing and upstreaming a solution for DisplayPort (DP) compliance in the Linux kernel DRM/i915 driver. The project addressed a widespread user issue: black screens or flickering displays when connecting systems to DisplayPort monitors or projectors due to failed link training. To solve this within the DRM atomic kernel mode setting (atomic KMS) framework, Navarre designed an asynchronous failure recovery mechanism centered around a new connector property.

### Key Topics - **DisplayPort Compliance & Link Training**: Ensuring hardware interoperability based on VESA DP specifications. Link training configures lanes and link rates across two critical phases: clock recovery and channel equalization. - **The Linux Graphics Stack & DRM KMS**: How user space communicates via DRM ioctls (`DRM_IOCTL_MODE_ATOMIC`) to the kernel DRM subsystem and hardware driver (i915), translating frame buffer pixels via CRTCs and encoders to connectors. - **The Atomic KMS Two-Step**: Atomic mode setting splits execution into `check` (validating configuration against hardware capabilities) and `commit` (writing to hardware, which is theoretically never supposed to fail). - **The Atomic Dilemma**: Link training physically interacts with the cable during `atomic commit`. Because cable physical limits are unknown during `atomic check`, link training can fail during `commit`, leaving users with black screens and no standard way to signal errors back to user space. - **Link Status Property Solution**: Adding a connector `link_status` property and asynchronous uevent mechanism to trigger user-space mode fallback. - **Open-Source Upstreaming Process**: Overcoming community review hurdles, handling kernel/user-space coordination, and adhering to core rules like preventing regressions.

### Technical Details Navarre utilized a VESA-certified Unigraf DPR-120 reference sink device connected between the test laptop and a DP monitor to execute compliance test suites by tapping AUX channel transactions and reading DPCD (DisplayPort Configuration Data) registers.

Under atomic KMS, `atomic check` guarantees that a requested display mode is theoretically valid, meaning `atomic commit` is expected to succeed unconditionally. Furthermore, atomic allows non-blocking commits where control returns to user space before the mode set finishes. However, physical DP link training must occur during `atomic commit`. If a cable cannot sustain the requested link rate (e.g., 5.4 Gbps for 4K/2K), link training fails, producing a black screen and kernel `dmesg` errors without recovery.

To resolve this without breaking atomic KMS design guarantees: 1. A new DRM connector property, `link-status`, was added with values indicating link health (such as `bad`). 2. When link training fails in the commit phase, the kernel driver sets `link-status` to `bad` and sends a hotplug uevent to user space. 3. Upon receiving the uevent, user space inspects the property, invalidates the failed mode, and initiates a new atomic mode set at a lower resolution and link rate. 4. Helper functions were introduced into the core DRM layer to allow both driver setting and user-space retrieval of the link status property. 5. The kernel retains previous failure state so that subsequent retraining attempts negotiate a lower link rate that the physical cable can accommodate.

### Takeaways Navarre highlighted several lessons for open-source kernel development: - **Linus's Rules**: The absolute priority is avoiding regressions (no black screens or GPU hangs). Kernel developers must design robust fallback solutions even when hardware behaves unpredictably. - **User-space/Kernel Chicken-and-Egg**: Co-dependent features require proving user-space support (such as mode-setting drivers utilizing new properties) before kernel changes can land. - **Open Development Practices**: Propose early designs as RFC patches on public mailing lists rather than writing isolated internal design documents. Expect extensive review cycles (over 15–20 revisions across a year), embrace constructive criticism, leverage IRC for maintainer communication, and persist through the upstreaming pipeline from mailing lists to DRM trees and Linux release candidates.