DEV Community

Deleon Karen
Deleon Karen

Posted on

Part 5: Display Topology and VidPN Management (Display Management)

#architecture #microsoft #systems #tutorial

In the WDDM world, the process of sending rendered pixels to the display is abstracted as a network structure called the VidPN (Video Present Network). Understanding the VidPN is the cornerstone for solving problems related to multi-monitor configuration, resolution switching, and hot-plugging.

1. Core Concepts and Object Model

The VidPN is the software model of the display adapter's presentational subsystem.

  • Video Present Source: Represents a scan-out controller (e.g., CRTC) inside the GPU. It is responsible for reading data from video memory.
  • Video Present Target: Represents a physical display connector (e.g., HDMI, DP, DVI).
  • Video Present Path: The association between a source and a target.
  • Topology: The collection of all paths in a VidPN, defining the structure of "what is displayed where" (1:1 extended, 1:N cloned).

VidPN Object Hierarchy:
A VidPN consists of a set of managed objects, with which the driver interacts through handles and interfaces. The core interfaces include:

  • DXGK_VIDPN_INTERFACE: Manages the top-level VidPN object.
  • DXGK_VIDPNTOPOLOGY_INTERFACE: Manages the topology structure.
  • DXGK_VIDPNSOURCEMODESET_INTERFACE & DXGK_VIDPNTARGETMODESET_INTERFACE: Manage mode sets.

2. Mode Negotiation: DxgkDdiEnumVidPnCofuncModality

This is one of the most complex functions in display driver development. Its task is to enumerate all "cofunctional" modes given constraints (the Constraining VidPN).

  • Enum Pivot: The OS specifies a pivot (such as a specific Source or Path) via EnumPivotType. The driver must keep the configuration of the pivot part unchanged, while adjusting other parts affected by it.
  • Constraint Handling: The driver needs to examine topology, pinned modes, scaling/rotation support, color spaces, etc.
  • Multisampling Support: The driver must also report the multisampling methods available for each Source under the currently pinned mode in this function.

3. Hot-Plug Handling (HPD)

The KMD informs the OS of each child device's capabilities by assigning an HPD Awareness value:

  • HpdAwarenessAlwaysConnected: Always connected (e.g., a laptop's built-in panel).
  • HpdAwarenessInterruptible: Supports hardware interrupt notification.
  • HpdAwarenessPolled: Does not support interrupts, requiring periodic polling by the OS (via DxgkDdiQueryChildStatus).

Processing Flow:

  1. Detection: Hardware generates an interrupt or the OS initiates a query.
  2. Notification: KMD calls DxgkCbIndicateChildStatus to report the connection status change.
  3. Response: The OS triggers VidPN re-enumeration and topology reconstruction.

4. Transformations: Scaling and Rotation

The driver needs to report its hardware's transformation capabilities to the OS.

  • Scaling Types:

    • Identity: The desktop resolution matches the monitor's resolution.
    • Centered: The desktop image is smaller than the monitor, centered with black borders.
    • Stretched: The image is forced to fill the screen, potentially causing distortion.
    • Aspect-Ratio-Preserving: Maximally stretched while maintaining the aspect ratio; the OS default preference.

  • Rotation:

    • The driver receives rotation instructions (0°, 90°, 180°, 270°) in DxgkDdiCommitVidPn.
    • Complexity in Clone Mode: In clone mode, different targets may have different physical orientations. The OS typically uses the rotation of the "primary target" as the baseline.
    • Path-Independent Rotation: Starting with Windows 8.1 Update, the driver can support independent offset rotations for different paths in clone mode, optimizing the user experience (e.g., keeping an external monitor landscape while the laptop screen is portrait).

5. Practical Development Advice

  • Strictly Follow Acquire/Release: All VidPN sub-object interfaces (e.g., pfnAcquireSourceModeSet) must be paired with a corresponding call to the Release function; otherwise, it will cause untraceable kernel memory leaks.
  • EDID Filtering: When enumerating modes, always acquire the monitor's native capabilities via pfnAcquireMonitorSourceModeSet and filter out any unsupported modes that the hardware cannot handle.
  • State Synchronization: When the hardware state changes unexpectedly (e.g., link bandwidth reduction due to signal degradation), proactively trigger synchronization via DxgkCbIndicateChildStatus.

Top comments (0)