Device Driver Interface

Article
06/30/2006

The Power Manager uses two mechanisms to communicate with power-managed drivers. The Power Manager calls down to a device driver to determine the device's capabilities and update its device power state. Devices may call up to the Power Manager to request device power state changes. Down calls are implemented as IOCTLs. Devices call up to the Power Manager with the DevicePowerNotify API.

Because the Power Manager uses DeviceIoControl to communicate with power-managed devices, such devices must expose a stream interface. In some situations, a power management proxy may expose the interface. Network Driver Interface Specification (NDIS) exposes a stream interface that enables proxy management of NDIS miniport drivers using the RegisterPowerRelationship API. The 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. A majority of devices support the stream interface, but this is not true in every instance. 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, the 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 Power Manager provided with Platform Builder only understands stream drivers, OEMs are free to implement additional device interfaces for their platform. You can accomplish this by defining a new class globally unique identifier (GUID) for devices that require the new API. Drivers using the new interface must adhere to the standard power-managed driver guidelines.

The default implementation of the Power Manager can detect the following GUIDs:

{A32942B7-920C-486b-B0E6-92A702A99B35} GUID for generic power-managed devices.
{8DD679CE-8AB4-43c8-A14A-EA4963FAA715} GUID for power-managed block devices.
{98C5250D-C29A-4985-AE5F-AFE5367E5006} GUID 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.

When applications call a Power Manager API that refers to a specific device, they should qualify the name of the device with the class associated with it. If the device name is not qualified with a class, the 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, the GUID {8DD679CE-8AB4-43c8-A14A-EA4963FAA715}\DSK1: refers to a power-managed block device named DSK1.

The 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. The following steps show you the process for implementing 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.
To recognize the GUID, modify the Power Manager, and use ExtEscape for devices associated with it.
To call AdvertiseInterface modify your display drivers using the new GUID.

Share via

Device Driver Interface

See Also

Additional resources