How Custom DisplayPort Resolutions Work Under the Hood

When a user defines a custom display resolution over a DisplayPort (DP) connection, the graphics processing unit (GPU) driver bypasses default display profile tables to calculate precise video timing parameters, negotiate link bandwidth, and restructure digital packet transport. This article explains the low-level sequence that occurs under the hood, from the initial timing calculation and hardware capability checks across the AUX channel to CRTC clock configuration and micro-packet framing across DisplayPort's high-speed Main Link.

1. Timing Calculation and Parameter Synthesis

The process begins in the graphics driver control panel (such as NVIDIA Control Panel, AMD Software, or Custom Resolution Utility). When horizontal pixels, vertical lines, and refresh rates are input, the driver synthesizes a full video timing profile:

  • Active Video Area: The visible resolution (e.g., \(2560 \times 1440\)).
  • Blanking Intervals: Horizontal and vertical blanking periods, which consist of the Front Porch, Sync Pulse, and Back Porch.
  • Timing Standards: The driver uses standardized formulas—most commonly VESA CVT (Coordinated Video Timings) or CVT-RB (Reduced Blanking). Reduced blanking eliminates legacy CRT delays, drastically lowering the required pixel clock for digital panels.
  • Pixel Clock Calculation: The GPU computes the exact pixel clock frequency using the formula:
    \[\text{Pixel Clock (Hz)} = \text{Total Horizontal Pixels} \times \text{Total Vertical Lines} \times \text{Refresh Rate (Hz)}\]

2. Physical Layer Bandwidth Verification

Once the pixel clock is derived, the GPU evaluates whether the required uncompressed data rate fits within the negotiated DisplayPort link budget.

The total required bandwidth is calculated based on the pixel clock and the color format (e.g., 24-bit for 8-bit RGB, 30-bit for 10-bit HDR): \[\text{Data Rate} = \text{Pixel Clock} \times \text{Bits Per Pixel (bpp)}\]

DisplayPort operates across 1, 2, or 4 physical lanes at fixed transmission rates:

  • RBR: 1.62 Gbps per lane
  • HBR: 2.70 Gbps per lane
  • HBR2: 5.40 Gbps per lane
  • HBR3: 8.10 Gbps per lane
  • UHBR 10/13.5/20: Up to 20 Gbps per lane (DisplayPort 2.x)

The driver calculates effective bandwidth by subtracting channel encoding overhead (8b/10b encoding consumes 20% of bandwidth in DP 1.4; 128b/132b consumes ~3% in DP 2.0+). If the custom resolution exceeds available bandwidth, the driver either denies the resolution, suggests Display Stream Compression (DSC) if supported by both ends, or reduces color bit depth.

3. AUX Channel Negotiation and DPCD Verification

DisplayPort uses a bidirectional, half-duplex sideband bus called the Auxiliary (AUX) Channel. Before applying changes:

  • The GPU reads the monitor's EDID (Extended Display Identification Data) and DisplayID blocks via the AUX channel to confirm physical panel boundaries and maximum pixel clock tolerances.
  • The GPU queries the sink's DPCD (DisplayPort Configuration Data) registers at addresses 00000h–000FFh. This confirms current link status: lane count, operational link rate, and whether clock recovery and symbol lock are already established.
  • If the custom timing demands an increase in the link rate (e.g., stepping up from HBR to HBR2), the GPU triggers a hardware link-training sequence over the AUX channel to calibrate voltage swing and pre-emphasis levels across the Main Link lanes.

4. GPU Display Controller (CRTC) Reconfiguration

With the transport validated, the GPU reconfigures its internal display engine (historically the CRTC, or Cathode Ray Tube Controller block):

  • Phase-Locked Loop (PLL) Tuning: The display PLL is reprogrammed to generate the exact target pixel clock.
  • Raster Engine Setup: Internal hardware counters for the horizontal total (\(H_{total}\)), vertical total (\(V_{total}\)), and synchronization pulse widths are updated in the display controller's register space.
  • Frame Buffer Scanning: The memory controller alters the scan-out engine addresses to fetch pixel data from system or video memory matching the new frame dimensions.

Unlike HDMI or DVI, which continuously transmit uncompressed pixel streams alongside a dedicated clock signal, DisplayPort packetizes video data over a self-clocked serialized link.

  • Packing into Transfer Units (TU): Active video data is broken down into 32-to-64 byte chunks called Transfer Units.
  • Framing Symbols: The GPU inserts special framing characters:
    • BS (Blanking Start) and BE (Blanking End) define active video versus blanking intervals.
    • FS (Fill Symbols) fill the remainder of the fixed-rate link bandwidth when the pixel data does not fully saturate the lane capacity.
  • Main Stream Attribute (MSA) Packets: The GPU regularly injects MSA data packets into the blanking intervals. The MSA contains critical metadata informing the monitor's hardware of the incoming custom signal: \(M_{vid}\) and \(N_{vid}\) values (used by the monitor to reconstruct the pixel clock), \(H_{total}\), \(V_{total}\), sync polarities, and color space flags.

6. Sink-Side Processing (Scaler and TCON)

At the receiving end:

  1. Clock Regeneration: The monitor's receiver uses an integrated PLL to recover the pixel clock using the \(M_{vid}\) and \(N_{vid}\) values transmitted in the MSA packets relative to the high-speed link clock.
  2. Unpacking and De-skewing: The receiver aligns the serialized data across all active physical lanes, strips framing symbols, and reconstitutes the raw RGB/YCbCr pixel stream.
  3. Scaler/TCON Acceptance: The stream is passed to the display scaler and Timing Controller (TCON). If the custom resolution matches the panel’s native pixel grid, the scaler is bypassed and the TCON directly drives the panel gate- and source-drivers. If the resolution differs from the native grid, the monitor's internal scaler maps the custom raster to the panel's physical array, unless GPU scaling is configured.