Plug and Play (PnP) in WDDM 1.2 and later
All Windows Display Driver Model (WDDM) 1.2 and later display miniport drivers must support the following behavior in response to start and stop requests by the Plug and Play (PnP) infrastructure. Behavior can differ depending on whether the driver returns a success or failure code, or whether the system hardware is based on the basic input/output system (BIOS) or Unified Extensible Firmware Interface (UEFI).
|Minimum WDDM version||1.2|
|Minimum Windows version||8|
|Driver implementation—Full graphics and Display only||Mandatory|
|WHCK requirements and tests||
Starting in Windows 8, the Microsoft DirectX graphics kernel subsystem provides this function that a driver can call if the display device is started or resumed from hibernation:
These functions and structure are available for the display miniport driver to implement WDDM 1.2 and later PnP requirements:
A Plug and Play (PnP) start process on the display device occurs either during boot or during an upgrade from one display driver to another. In this case the driver must call the DxgkCbAcquirePostDisplayOwnership function to get information about the frame buffer and to maintain display synchronization. Frame buffer information is provided either from the firmware or from the previous WDDM 1.2 and later driver that was loaded on the system.
During calls the operating system makes to DxgkDdiSetPowerState function to return to the D0 power state, and to the DxgkDdiStartDevice function, the WDDM 1.2 and later driver must set source visibility to false (DXGKARG_SETVIDPNSOURCEVISIBILITY.Visible = FALSE) for all active video present network (VidPN) targets. In this case the display pipeline hardware must maintain sync signals with the monitor, but the pipeline must continue to send black pixel data to the monitor no matter what pixel data is present in the surface that's currently being scanned out. This means that the pixel pipeline is guaranteed to be blanking the monitor with all black pixels. Later, when the first frame is rendered into the frame buffer, the operating system sets source visibility to true.
All of these procedures keep the monitor synchronized and ensure that the user doesn't see flashes or flickers on the screen.
These are the return codes that the driver should return after a PnP start process.
|Driver return code||Description|
Behavior is the same as in Windows 7.
For a BIOS-based system, if the driver starts successfully, the frame buffer is still active and the driver must be ready to set to a valid mode.
For a BIOS-based system, the driver must leave the system in a BIOS-compatible state.
For a UEFI-based system, the driver must leave the display in the same mode that was set by the UEFI Graphics Output Protocol (GOP) so that the basic display driver can use the display. The driver must return a valid error code. If the driver cannot leave the GOP in a state that can be used by the basic display driver, the driver must return the STATUS_GRAPHICS_STALE_MODESET error code from Ntstatus.h, and the operating system causes a system bugcheck to occur.
A Plug and Play (PnP) stop process on the display device typically occurs when a driver is being upgraded to a new version. In this case the operating system calls the driver's DxgkDdiStopDeviceAndReleasePostDisplayOwnership function, which requires the driver to provide accurate frame buffer information.
In the DxgkDdiStopDeviceAndReleasePostDisplayOwnership call the driver must ensure that the source visibility for the active VidPn targets is true (DXGKARG_SETVIDPNSOURCEVISIBILITY.Visible = TRUE). In addition, starting in WDDM 1.2 the driver needs to ensure that the surface that the pixel pipeline is programmed to scan out from is filled with black pixels. The driver should complete filling the surface with black pixels before before source visibility is set to true.
Be sure to also implement DxgkDdiStopDevice in your driver. In some cases the operating system might call DxgkDdiStopDevice instead of DxgkDdiStopDeviceAndReleasePostDisplayOwnership, or after a call to DxgkDdiStopDeviceAndReleasePostDisplayOwnership fails.
These are the return codes that the driver should return after a PnP stop process.
|Driver return code||Description|
Before the driver is stopped it must set up a frame buffer, using the current resolution, that the basic display driver can use, and the driver must return this information when the operating system calls the DxgkDdiStopDeviceAndReleasePostDisplayOwnership function. The saved mode information doesn't have to be compatible with BIOS, and the basic display driver won't offer a BIOS mode until the system is rebooted.
Success, and driver sets the Width and Height members of the DXGK_DISPLAY_INFORMATION structure to zero
This scenario is possible only if the system has two graphics cards, no monitors are connected to the current power-on self-test (POST) device, and the operating system calls the DxgkDdiStopDeviceAndReleasePostDisplayOwnership function to stop the POST device.
In this case the current display continues to run on the second graphics adapter, and the basic display driver runs in headless mode on the adapter that supports the POST device.
The operating system calls the Windows 7-style PnP stop driver interface through the DxgkDdiStopDevice function.
For a BIOS-based system, the driver must set the display into a BIOS-compatible mode.
For a UEFI-based system, the basic display driver runs in headless mode on the graphics adapter.
For further requirements on PnP and other state transitions, see Providing seamless state transitions in WDDM 1.2 and later.
For info on requirements that hardware devices must meet when they implement this feature, refer to the relevant WHCK documentation on Device.Graphics.WDDM12.Display.PnpStopStartSupport.
See WDDM 1.2 features for a review of features added with Windows 8.