Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

To configure system-activity and user-activity timeouts, use the Power Control Panel applet. You can also implement additional timers and set their timeouts by editing the registry directly. Windows Embedded CE does not limit the number of timers you can create. At startup, Power Manager reads the registry keys, enumerates the activity timers, and creates the associated events. Table 3-16 lists the registry settings for the SystemActivity timer. OEMs can add similar registry keys and configure these values for additional timers.

Table 3-16 Registry settings for activity timers

Defining activity timers causes the Power Manager to construct a set of named events for resetting the timer and for obtaining activity status. For more information, see the section "Activity Timers" in the Windows Embedded CE 6.0 Documentation available on the Microsoft MSDN website at http://msdn2.microsoft.com/en-us/library/aa923909.aspx.

As mentioned earlier in this lesson, Power Manager exposes three interfaces to enable applications and drives for power management: notification interface, driver interface, and application interface.

The notification interface provides two functions that applications can use to register and deregister for power notifications through message queues, as listed in Table 3-17. It is important to note that power notifications are multicast messages, which means that Power Manager sends these notification messages only to registered processes. In this way, power management-enabled applications can seamlessly coexist on Windows Embedded CE with applications that do not implement the Power Management API.

Table 3-17 Power Management notification interface

The following sample code illustrates how to use power notifications:

// Size of a POWER_BROADCAST message.

DWORD cbPowerMsgSize =

sizeof POWER_BROADCAST + (MAX_PATH * sizeof TCHAR);

// Initialize a MSGQUEUEOPTIONS structure.

MSGQUEUEOPTIONS mqo;

mqo.dwSize = sizeof(MSGQUEUEOPTIONS);

mqo.dwFlags = MSGQUEUE_NOPRECOMMIT;

mqo.dwMaxMessages = 4;

mqo.cbMaxMessage = cbPowerMsgSize;

mqo.bReadAccess = TRUE;

//Create a message queue to receive power notifications.

HANDLE hPowerMsgQ = CreateMsgQueue(NULL, &mqo);

if (NULL == hPowerMsgQ) {

RETAILMSG(1, (L"CreateMsgQueue failed: %x\n", GetLastError()));

return ERROR;

}

// Request power notifications.

HANDLE hPowerNotifications = RequestPowerNotifications(hPowerMsgQ,

PBT_TRANSITION | PBT_RESUME | PBT_POWERINFOCHANGE);

// Wait for a power notification or for the app to exit.

while(WaitForSingleObject(hPowerMsgQ, FALSE, INFINITE) == WAIT_OBJECT_0) {

DWORD cbRead;

DWORD dwFlags;

POWER_BROADCAST *ppb = (POWER_BROADCAST*) new BYTE[cbPowerMsgSize];

// Loop through in case there is more than 1 msg.

while(ReadMsgQueue(hPowerMsgQ, ppb, cbPowerMsgSize, &cbRead, 0, &dwFlags)) {

// Perform action according to the message type.

}

}

In order to integrate with the Power Manager, device drivers must support a set of I/O controls (IOCTLs). Power Manager uses these to query device-specific power capabilities as well as to set and change the device's power state, as illustrated in Figure 3-10. Based on the Power Manager IOCTLs, the device driver should put the hardware device into a corresponding power configuration.

Figure 3-10Power Manager and device driver interaction

Power Manager uses the following IOCTLs to interact with device drivers:

■ IOCTL_POWER_CAPABILITIESPower Manager checks the power management capabilities of the device driver. The returned information should reflect the capabilities of the hardware and the driver managing the hardware device. The driver must return only supported Dx states.

■ IOCTL_POWER_SETPower Manager forces the driver to switch to a specified Dx state. The driver must perform the power transition.

■ IOCTL_POWER_QUERYPower Manger checks to see if the driver is able to change the state of the device.

■ IOCTL_POWER_GETPower Manager wants to determine the current power state of the device.

■ IOCTL_REGISTER_POWER_RELATIONSHIPPower Manager notifies a parent driver to register all child devices that it controls. Power Manager sends this IOCTL only to devices that include the POWER_CAP_PARENT flag in the Flags member of the POWER_CAPABILITIES structure.

To ensure reliable power management, device drivers should not change their own internal power state without the involvement of Power Manager. If a driver requires a power state tran­sition, the driver should use the DevicePowerNotify function to request the power state change. The driver can then change its internal power state when Power Manager sends a power state change request back to the driver.

The application interface provides functions that applications can use to manage the power state of the system and of individual devices through Power Manager. Table 3-18 summarizes these power management functions.

Table 3-18 Application interface