Display Driver Initialization

Although most of display driver initialization is generally the same as that for graphics drivers, there are a few details specific to display drivers. This section presents a brief synopsis of the process. See the Programmer’s Guide for more information about the boot process.

Video miniport and display driver initialization occur after the Windows NT executive and the Win32 subsystem are loaded and initialized. It is USER who opens video miniport driver(s) enabled in the registry and then determines which video miniport driver and display driver pair to use. During this determination, GDI opens all necessary display drivers, based on the information provided by Window Manager. Figure 5.1 shows the basic display driver initialization procedure.

Figure 5.1 Display Driver Initialization

• When GDI is called to create the first DC for the video hardware, GDI calls the display driver function DrvEnableDriver. Upon return, DrvEnableDriver furnishes GDI with a DRVENABLEDATA structure that holds both the driver version number and the entry points of all functions the driver chooses to support that GDI can call (other than DrvEnableDriver and DrvDisableDriver).

• GDI then typically asks for a physical device to be created by a call to the display driver function DrvEnablePDEV. The call uses the GDI DEVMODEW structure to identify the exact device and mode that GDI wants to access. The display driver initializes the hardware to a known state by sending requests to the video port-miniport driver pair. If GDI requests a mode that the display or underlying miniport driver does not support, the display driver must fail this call.

• The display driver represents a logical device controlled by GDI. A single logical device can manage several physical devices, each characterized by type of hardware, logical address, and surfaces supported. The display driver allocates the memory to support the device it creates. A display driver can manage more than a single display defined as a PDEV. The display driver copies device information to a PDEV structure representing the display and its current operating state. DrvEnablePDEV can be called more than once by GDI, with each call creating another PDEV that is used with a different surface. However, an actual surface is not supported until the GDI calls DrvEnableSurface.

  If a driver is to support more than one PDEV, it must not use global variables.

• When installation of the physical device is complete, GDI calls the display driver DrvCompletePDEV function. This function provides the driver with a physical device handle to be used when requesting GDI functions for the device.

• As the final stage of initialization, a surface is created for the video hardware by a GDI call to DrvEnableSurface which enables graphics output to the hardware. Depending on the device and the environment, the display driver enables a surface in one of two ways:
  • The driver manages its own surface by calling the GDI function EngCreateDeviceSurface to obtain a handle for the surface. The device-managed surface method is required for hardware that does not support a standard-format bitmap and is optional for hardware that does.

  • GDI can manage the surface completely as an engine-managed surface if the hardware device has a surface organized as a standard-format bitmap. Even in this case, when it calls EngAssociateSurface, the driver can still hook any drawing functions that it can more efficiently handle.

The display driver can obtain a bitmap handle for a surface by calling EngCreateBitmap with a pointer to the device pixels. GDI collects the graphics directly in a bitmap. The display driver calls EngCreateBitmap, allowing the GDI to allocate space for the pixels.

Any existing GDI bitmap handle is a valid surface handle. Before returning a surface, the display driver must associate it with the PDEV, using a call to EngAssociateSurface, specifying which functions it wishes to hook for drawing to the surface. If the surface is engine-managed, GDI can handle any or all drawing operations. If the surface is device-managed, at a minimum, the driver must handle DrvTextOut, DrvStrokePath, and DrvCopyBits.