[MDA III, XDA III, PDA2k, 9090 General] fusedwire:
I found this information from the following link:

http://66.249.93.104/search?q=cache...t/html/WinCEFAQ.asp+disablegwespoweroff&hl=en

In general terms, how does the Power Manager work?

The Power Manager acts as a mediator between the following three entities:

* Devices, which may be able to intelligently manage their own power.

* The OEM, who defines system power states that restrict how much power devices can consume.

* Applications, which need to receive notifications of power-related events and which may want to maintain devices they are using at some minimum power level.

The Power Manager implements the following set of rules for making these three parties work together:

* System power states impose power consumption ceilings on all devices.

* Applications impose power consumption floors on specific devices (to obtain minimum performance levels).

* The Power Manager will allow devices to intelligently manage their own power as long as they keep their power levels between the ceiling and the floor.

* If the floor is higher than the ceiling the device's power will remain elevated for as long as the application requires the device.

* If the system transitions to a suspend system power state, application-imposed "floors" will be set aside while the system is suspended.

How do OEMs, device driver writers, and applications interact with the Power Manager?

OEMs set up named system power states in the Registry. These have the following characteristics:

* They define a maximum, or ceiling, device power level.

* They can include a set of hint flags that tell the Power Manager how to handle transitions into the power state.

For example, the POWER_STATE_SUSPEND flag tells the Power Manager that it will need to call PowerOffSystem() in addition to changing device states.

The OEM will generally customize the Power Manager to have special knowledge about which state is appropriate at any given time, based on the system's environment. For example, an OEM may define states for being on battery, on low battery, on AC power, in cradle, out of cradle, and so forth.

Power manageable devices have the following characteristics:

* They need to advertise a power management interface that the Power Manager understands. This is generally the default GUID, {A32942B7-920C-486b-B0E6-92A702A99B35}. They can do this using AdvertiseInterface() or by adding their GUID to the IClass REG_MULTI_SZ value in their configuration registry key.

* When the device becomes available, the Power Manager will send it an IOCTL_POWER_CAPABILITIES request to which it must respond.

* The Power Manager will update the device's power state using IOCTL_POWER_SET calls.

* If a device driver wants to intelligently manage the power of its device, it can request power updates using the DevicePowerNotify() API. These may or may not cause the Power Manager to issue an IOCTL_POWER_SET at some point in the future.

Applications can interact with the Power Manager in the following ways:

* They can request notifications of power-related events using RequestPowerNotifications(). When they no longer need notifications they can call StopPowerNotifications().

* They can request to keep devices they are using at a minimum power level using SetPowerRequirement(). They should keep requirements in effect for the shortest possible time, and then release them with ReleasePowerRequirement().

Can we get any useful information out of this to get bluetooth working on the blueangel flawlessly for WM5??