Upon initialization, Power Manager reads the registry to acquire a list of activity timer names. For each timer, Power Manager checks for a timeout and an optional list of wake sources. It then creates the following named events:

• A timer reset event
  
  
• An active status manual-reset event
  
  
• A manual-reset event
  
  

If the timeout associated with the timer expires without a reset event, Power Manager signals the active event and sets the inactive event. If the reset event is signaled, Power Manager signals the inactive event and sets the active event.

The following code example is a registry setting for configuring an activity timer:

	Copy Code
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\ActivityTimers\UserActivity] "Timeout"=dword:A "WakeSources"=multi_sz:"0x20"

This set of registry values causes Power Manager to create three events with the following names:

• PowerManager/ActivityTimer/UserActivity
  
  
• PowerManager/UserActivity_Active
  
  
• PowerManager/UserActivity_Inactive
  
  

The first event is an auto-reset event that any driver can signal to indicate system activity. Drivers that support resetting activity timers read the name of the timer reset event from the registry. The other events are manual reset events, of which only one is signaled at a time. Drivers, applications, or Power Manager itself can open handles to these events to determine whether the timer has expired. These events indicate the status of the activity timer. The reset event is an input to the activity timer system, and the status events are the corresponding outputs.

In addition to creating events, this set of registry entries associates a wake source identifier for the activity timer. If the OS resumes and Power Manager determines that the wake source corresponding to this ID caused the system to resume, Power Manager sets the associated activity timer to active. Power Manager uses the IOCTL_HAL_GET_WAKE_SOURCE kernel I/O control code to determine what woke the system. OS power state transitions can use an activity timer as input to determine when to transition to another power state. The activity timer uses that input to choose which system power state is the most appropriate to enter during the resuming process. For example, Power Manager might enter an OS power state in which the display and backlight are off. Power Manager enters this state so that network synchronization can occur without disturbing the user.

Any number of drivers can open handles to the reset event of an activity timer. Drivers can signal the activity timer when appropriate. A driver should read the name of the event from the registry to obtain OEMs customizations set in the registry. By customizing the registry, the OEMs decide how the activity of a driver is interpreted by Power Manager. Potential sources of activity include all drivers that open handles to the reset event of the activity timer.

Any number of threads can open handles to the manual-reset activity/inactivity events and wait for them to determine the status of the OS. For example, a backlight driver can use the pair of manual-reset events created for an activity timer to decide how to control backlight power and intensity.

When the system is suspended, Power Manager signals the active manual-reset events associated with activity timers. On a resume event, it scans the timers to see if any are associated with the wake source that caused the system to resume. If it finds a match, that activity event is signaled. This enables Power Manager to resume in the system power state associated with that activity timer.

A keypad press or touch-panel tap can reset the activity timer.

See Also