Device Driver Interface (Windows Embedded CE 6.0)
1/6/2010
Power Manager uses two mechanisms to communicate with power-managed drivers. Power Manager calls a device driver to determine device capabilities and update its device power state. Devices call Power Manager to request device power state changes. Calls from Power Manager are implemented as I/O controls. Devices call Power Manager with the DevicePowerNotify function.
Because Power Manager uses DeviceIoControl to communicate with power-managed devices, such devices must expose a stream interface. In some situations, a power management proxy can expose the interface. Network Driver Interface Specification (NDIS) exposes a stream interface that enables proxy management of NDIS miniport drivers, using the RegisterPowerRelationship function. Power Manager provides a mechanism for communicating directly with non-stream drivers. This method consists of an abstraction layer for opening a handle to a device, sending a request, and so on. Most, but not all, devices support the stream interface. For example, the driver located in Public\Common\Oak\Drivers\Pm\Mdd\Pmdisplay.cpp implements a communication interface based on the ExtEscape function.
Opening standard device names of the format COM1:, and so on, allows access to drivers that expose a stream interface. However, Power Manager does not require that power-manageable devices use this naming format. A device name can be any unique string. So, for example, an NDIS miniport might be named VMINI1.
Although the default implementation of Power Manager in Platform Builder understands stream drivers, OEMs are free to implement additional device interfaces for their run-time image. You can accomplish this by defining a new class globally unique identifier (GUID) for devices that require the new interface. Drivers using the new interface must adhere to the standard power-managed driver guidelines.
The default implementation of Power Manager can detect the following GUIDs:
- {A32942B7-920C-486b-B0E6-92A702A99B35} for generic power-managed devices.
- {8DD679CE-8AB4-43c8-A14A-EA4963FAA715} for power-managed block devices.
- {98C5250D-C29A-4985-AE5F-AFE5367E5006} for power-managed NDIS miniports.
Applications can get a list of power-managed classes by enumerating the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\Interfaces registry key.
If an application calls a Power Manager function without qualifying the device with a class, Power Manager assumes that the device belongs to the generic power-managed device class.
Class-qualified device names are prefixed with the class GUID rendered as a string, followed by a backslash (\). For example, {8DD679CE-8AB4-43c8-A14A-EA4963FAA715}\DSK1: refers to a power-managed block device named DSK1.
Power Manager reads a list of device classes from the registry and uses RequestPowerNotifications to determine when devices of that class are loaded. The following code example shows a device class list:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\Interfaces]
"{A3292B7-920C-486b-B0E6-92A702A99B35}"="Generic power-manageable devices"
"{8DD679CE-8AB4-43c8-A14A-EA4963FAA715}"="Power-manageable block devices"
"{98C5250D-C29A-4985-AE5F-AFE5367E5006}"="Power-manageable NDIS miniports"
The sample Power Manager implementation assumes these settings. You do not need to include them in the registry, unless you want to add additional keys. Use the following steps to implement a class representing display drivers that can be managed using ExtEscape codes directly:
- Create a new class GUID with Guidgen.exe, and add it to the registry.
- Modify Power Manager to recognize the GUID, and use ExtEscape for devices associated with it.
- Modify your display drivers, using the new GUID, to call AdvertiseInterface.
See Also
Reference
DevicePowerNotify
RegisterPowerRelationship
RequestPowerNotifications
Concepts
Power Manager Interfaces
Device Control I/O Controls
Driver-to-Power Manager Functions