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 DevicePowerNotifyfunction.

Because Power Manager uses DeviceIoControlto 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 RegisterPowerRelationshipfunction. 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 ExtEscapefunction.

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\Interfacesregistry 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 RequestPowerNotificationsto determine when devices of that class are loaded. The following code example shows a device class list:

	Copy Code
[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 ExtEscapecodes directly:

1. Create a new class GUID with Guidgen.exe, and add it to the registry.
   
   
2. Modify Power Manager to recognize the GUID, and use ExtEscapefor devices associated with it.
   
   
3. Modify your display drivers, using the new GUID, to call AdvertiseInterface.
   
   

See Also