Display Driver Development Concepts (Windows CE 5.0)

Article
09/14/2012

Display drivers are loaded and called directly by the graphics, windowing, and event subsystem, called Gwes.exe. Drivers are most commonly written using a layered architecture because of the number of hardware-independent operations.

The Graphics Primitive Engine (GPE) library handles the default drawing, acting as the display driver's model device driver (MDD) upper layer.

You develop the hardware-specific code that corresponds to the display driver's lower layer, called the platform-dependent driver (PDD).

The following table shows the elements that constitute the Windows CE graphics pipeline.

Element	Description
Application	The application can be simple, such as a Hello World application, or complex, such as a three-dimensional engineering application. Whichever it is, the application calls GDI functions. Coredll.dll exposes these functions.
Coredll.dll	The major set of functions is exposed through a single DLL, called Coredll.dll. In most cases, this library does not perform the work. Instead, the library packages the parameters for the function call and then triggers a Local Procedure Call (LPC) to another process. The specific process depends on the function call. All drawing and windowing calls are sent to Gwes.exe.
Gwes.exe	The Graphics, Windowing and Events Subsystem (GWES) is responsible for all graphical output and all interactions with the user. The drivers that reside in the GWES address space include display drivers, printer drivers, keyboard drivers, mouse drivers, and touch screen drivers.
Ddi.dll	The default name for the display driver is Ddi.dll. As with most DLLs, Ddi.dll communicates through exported functions. Ddi.dll exports only the DrvEnableDriver function, which returns a pointer to an array of 27 function pointers to the caller. When GWES requires a display driver, it calls one of these 27 functions. Writing a device driver involves writing the code for these 27 functions. Three of these functions are specific to printer drivers, which leaves 24 for the display driver developer.
Hardware	The graphic pipeline ends at the hardware. The display driver communicates to the hardware using the mechanism required by the hardware. This process typically involves a combination of memory-mapped video buffers and I/O registers.

The following illustration shows the Windows CE graphics architecture.

Aa447495.displayarch(en-us,MSDN.10).gif

You can minimize the amount of time and effort that is needed to create a display driver by customizing a sample driver provided with Platform Builder. The sample drivers take advantage of the GPE class to provide default drawing with hardware-specific issues.

The GDI makes calls to the display driver and the display driver writes to the physical display device. All Windows CE–based display drivers must implement a set of display DDI functions that you use to initialize the display driver and block image transfer (blit) to the display.

The GPE classes serve as a base of code that you can use to derive new display drivers for your hardware. The GPE classes handle all communication within the display DDI layer and handle the default drawing. Using the GPE classes can save development and debugging work.

The sample display drivers use the GPE. They demonstrate how you can add extensions to the display driver, for example, to enable hardware accelerations.

If you use the GPE classes, you must provide code necessary to ensure that your display device operates correctly. In addition, if your device supports hardware acceleration for BitBlt transfers, you can also enable hardware acceleration.

Be aware that using the GPE classes involves hardware requirements.

The GPE classes are for display devices that support a flat-frame buffer. Flat-frame implies that all display device memory must be in a single block of contiguous memory.

All display driver controls write to the built-in display hardware of the system. This hardware can be an LCD screen or any display hardware that is suitable for your hardware platform. Display driver models for built-in display hardware and peripheral display adapter drivers are the same.

To store configuration entries for your display driver, create a registry key under HKEY_LOCAL_MACHINE\Drivers\Display. The initialization routine of your display driver should create keys under HKEY_LOCAL_MACHINE\Drivers\Display\Active so applications can determine which display devices are available.

PCI-based display drivers can benefit from the PCI bus driver loading model.

The PCI bus driver, the hardware platform's BIOS, or both, enumerate and program the PCI configuration space of the device, and populate the registry with configuration information. The display driver can then read this registry information without having to scan the bus for its device and read the PCI configuration space itself.

For an example, see the DisplayInit and MapPhysicalDevice functions for the MQ200 driver in %_WINCEROOT%\Public\Common\OAK\Drivers\Display\MQ200\Devmap.cpp.

GWES writes the driver it is using to HKEY_LOCAL_MACHINE\System\GDI\Drivers\MainDisplay.

To determine which display driver to load, GWES uses the following procedure:

GWES checks the list of candidate displays in HKEY_LOCAL_MACHINE\System\GDI\DisplayCandidates to determine if any are instantiated on the local system. This list is usually created in Platform.reg.
If so, GWES uses the first one it finds.
GWES attempts to load Ddi.dll, which is the default display driver name.
A registry entry in Common.reg loads Ddi.dll.

A dedicated process can load secondary drivers by calling CreateDC with "MyDDI.dll" as the first parameter. For more information, see Secondary Display Drivers.

GWES allows you to create run-time images that determine the display adapter at run time and load the appropriate driver. The PCI instance data can specify the display adapter. If it is possible that no display adapter is present, you can use Ddi_nop.

For example, assume that a device could have a ATI Rage XL Expert 98 card in a PCI slot. To create an image to support this, do the following:

Set BSP_DISPLAY_RAGEXL=1, and BSP_DISPLAY_NOP=1.
Create PCI templates and a GDI candidate list in your Platform.reg file.

If the PCI bus driver detects a display adapter card, it creates a PCI instance key that GDI uses to load the driver.

If no adapter cards are found, the Ddi_nop driver is loaded because it appears after the others, as shown in the following registry example.

IF BSP_NODISPLAY !

IF BSP_DISPLAY_MQ200
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_mq200.dll"

;
;MediaQ MQ200 driver settings
;
[HKEY_LOCAL_MACHINE\Drivers\Display\MQ200]
   "Rotate"=dword:0
   "PPSupport"=dword:0
   "PPSupportEnable"=dword:0

;; 640x480x16
   "CxScreen"=dword:280
   "CyScreen"=dword:1E0
   "BPP"=dword:10
   "Freq"=dword:3C

;; FB_BASE address
   "FB_BASE"=dword:00000000

;; OEM run time flag
   "Flag"=dword:00030503

   "MIU2"=dword:00EA0086
   "MIU3"=dword:6C4848C4
   "MIU5"=dword:00000119
   "DC0"=dword:0EF2082A
   "PLL1Freq"=dword:00530000

   "PWM"=dword:000000A1

[HKEY_LOCAL_MACHINE\Drivers\Display\MQ200\Color]
;; Cursor Color setting
   "CC"=dword:F

;
; MQ200 supports saving/restoring video memory surfaces during
suspend/resume.
;
[HKEY_LOCAL_MACHINE\SYSTEM\GWE]
    ; "PORepaint"=dword:0 - the display driver handles everything
    ; "PORepaint"=dword:1 - gwe should save and restore the bits
    ; "PORepaint"=dword:2 - gwe should invalidate and repaint
    ; "PORepaint"=dword:3 - gwe and driver need to save video memory
    ;
    "PORepaint"=dword:3
ENDIF

IF BSP_DISPLAY_SMI3DR
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_3dr.dll"
ENDIF

IF BSP_DISPLAY_RAGEXL
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_ragexl.dll"
ENDIF   

IF BSP_DISPLAY_PERM3
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_perm3.dll"
ENDIF

IF BSP_DISPLAY_PERM3_SWG
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_perm3_swg.dll"
ENDIF

IF BSP_DISPLAY_ATI
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_ati.dll"
ENDIF

IF BSP_DISPLAY_S3V
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_s3v.dll"
ENDIF

IF BSP_DISPLAY_RFLAT
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_rflat.dll"
ENDIF

IF BSP_DISPLAY_FLAT
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_flat.dll"
ENDIF

IF BSP_DISPLAY_NOP
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
    "Display"="ddi_nop.dll"
ENDIF

ENDIF BSP_NODISPLAY !

Partager via

Display Driver Development Concepts (Windows CE 5.0)

See Also

Ressources supplémentaires