Edit

Share via

Indirect display driver overview

  • Article

The indirect display driver (IDD) model provides a simple user-mode driver model to support monitors that aren't connected to traditional GPU display outputs. Some typical scenarios where an IDD is required include:

  • Streaming the display output over a network to a remote client (remote display).
  • Creating virtual monitors for applications such as virtual desktop environments (virtual displays).
  • Connecting a dongle to a PC via USB that has a regular monitor (VGA, DVI, HDMI, DP, etc.) connected to it.

IDD implementation

An IDD is the third party-provided UMDF driver for the device. You can develop an IDD using the functionality exposed by the IddCx (Indirect Display Driver Class eXtension) to interface with the windows graphics subsystems in the following ways:

  • Create the graphics adapter representing the indirect display device.
  • Report monitors being connected and disconnected from the system.
  • Provide descriptions of the monitors connected.
  • Provide available display modes.
  • Support other display functionality, such as hardware mouse cursor, gamma, I2C communications, and protected content.
  • Process the desktop images to display on the monitor.

Because an IDD is a UMDF driver, it's also responsible for implementing all UMDF functionality such as device communications, power management, plug and play, and so forth.

The IDD runs in Session 0 without any components running in the user session, so any driver instability doesn't affect the stability of the system as a whole.

The following diagram provides an architectural overview.

Diagram that shows the indirect display driver within the UMDF architecture.

User-mode model

The IDD is a user-mode only model with no support for kernel-mode components. As such, the driver is able to use any DirectX APIs in order to process the desktop image. In fact, the IddCx provides the desktop image to encode in a DirectX surface.

The driver shouldn't call user-mode APIs that aren't appropriate for driver use, such as GDI, windowing APIs, OpenGL, or Vulkan.

The IDD should be built as a universal windows driver so it can be used on multiple Windows platforms.

At build time:

  • The UMDF IDD declares the version of IddCx it was built against.
  • The OS ensures that the correct version of IddCx is loaded when the driver is loaded.

IddCx callback and function naming conventions

Prefix Type Notes
EVT_IDD_CX_XXX IDD callback function IDDs implement both IddCx-specific callbacks such as EVT_IDD_CX_ADAPTER_COMMIT_MODES, and relevant WDF callbacks such as EVT_WDF_DEVICE_D0_EXIT.
IddCxXxx Function System-supplied IddCx class extension functions that IDDs can call; for example, IddCxAdapterInitAsync.
PFN_IDDCX_XXX Pointers to IddCx functions IDDs don't use these pointers. Instead, drivers should use the equivalent IddCxXxx functions.

Sample code

Microsoft provides a sample IDD implementation at the Windows Driver Samples GitHub. This sample demonstrates how to connect a monitor, how to respond to a mode set, and how to receive frames.