Power to the System

Power to the Developers part 2

Windows Mobile Team Blog — Fri, 12 Aug 2005 01:36:28 GMT

In Power to the People we learned that it's very bad for your app to use the CPU unnecessarily.&nbsp;...

Power to the Developers part 2

Windows Mobile Team Blog — Fri, 12 Aug 2005 20:15:28 GMT

In Power to the People we learned that it's very bad for your app to use the CPU unnecessarily.&nbsp;...

re: Power to the System

John Wei — Thu, 18 Aug 2005 13:44:32 GMT

Can you teach me how get into Unattended mode when wake up, like ativesync doing the sync .
I mean that every 5 minutes , my app wake up in the unattended mode,do some task ,into supsend mode. and repeat again after 5 minutes later.are ther any api can achieve that?
i have used the CeRnAppAtTime.But my app was run in On state...
please mail me the answer
my address is wjr87u@yahoo.com.tw
thank you so much.
best regards

Windows Mobile Power States

Mikel Berger — Fri, 19 Aug 2005 02:33:10 GMT

A good read for CPT 355 about power for Windows Mobile devices http://blogs.msdn.com/windowsmobile/archive/2005/08/01/446240.aspx This is part of series on power, but one of the more interesting parts is the list of power states for smartphones and Pocket PCs from this post http://blogs.msdn.com/windowsmobile/archive/2005/08/10/450186.aspx * On: The user is interacting with the device. Everything is on. * BacklightOff: There has been a brief period of user inactivity (no one has pressed any buttons or touched a touchscreen). The backlight has been turned off, but everything else is on. When you set the backlight timeout values in the control panel, you're setting how long the system should wait before going into this state. (Note that this state is new for WM 5.) * UserIdle: There has been a longer period of user inactivity. Both the backlight and LCD have been turned off. When you set the screen timeout value on a Smartphone control panel, you're setting how long the system should wait before going into this state. This state is generally not used on PocketPC. There's no reason to turn the screen off when the device is about to go to sleep (sleeping turns the screen off). However, if/when PocketPCs go to the "Always On" model, they'll start using this state. * ScreenOff: You go into this state when someone specifically says to turn the screen (and backlight) off. For instance, in Media Player you can assign a button to turn the screen off. When you press it, we go into this state. This state is different than UserIdle, though. This state says, "The user wants the screen off and doesn't want it to turn back on." UserIdle says, "The user hasn't touched any buttons in a while, so we might as well turn the screen off to save power." In ScreenOff, pressing a button (other than the power button) doesn't turn the screen back on. In UserIdle, pressing a button does turn the screen back on. Both PocketPC and Smartphone use this state. * Unattended: This is a confusing state in which the screen, the backlight, and the audio are off. I won't go into too many details, other than to say that this is a PocketPC-only state that is used by applications which need to do things without alerting the user. While the PocketPC is in this state, the user thinks the device is asleep. For instance, ActiveSync when it syncs every 5 minutes. It's waking up, syncing, and going back to sleep, but the user can't tell. * Resuming: This is the state the PocketPC goes into when it wakes up from sleep. In this state, the screen is off, and there is a very short (15 second) timer before it goes back to sleep. The only way to keep the device from going back to sleep is to have something put it into one of the other states. This is really for dealing with spurious wakeups and for giving the system a way to get into Unattended without letting the user know about it. * Suspended: This is the PocketPC "Sleep" state. Everything is off, and the system isn't going to wake back up until some piece of hardware wakes it up. It's not actually an official Power Manager state, the way the other six are, but I'm including it for completeness....

re: Power to the System

windowsmobile — Mon, 19 Sep 2005 20:47:36 GMT

John, I'm sorry, I missed your comment back when. I was just checking through comments now and saw it.

Here's how to enter and leave unattended mode.

If you call:
PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE);
at the start of your app, it will enter unattended.

Then, when you're ready to exit, call
PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE);
That will tell the system that you're done.

This is what ActiveSync does.

Mike Calligaro

re: Power to the System

MadDogX007 — Wed, 19 Apr 2006 14:51:48 GMT

Is there anyway to automatically run application unattended on WM5?

In otherwods, is there some consumer utility that will run an applicatin in WM5, unattended?

re: Power to the System

MikeCal — Sat, 22 Apr 2006 02:06:10 GMT

MadDog, are you asking if it's possible to say, "I'd like this application that's already on the device to run in unattended"?

If you can't change the application's code, you can't make the application itself run in unattended.

One thing you could do is have an application that puts the system into unattended and keeps it there. I'm not sure if that's what you're looking for, though.

Can you tell me more about what you're trying to do? What application would you like to be unattended and when?

Mike

re: Power to the System

kernel — Wed, 03 May 2006 03:27:36 GMT

Here's one for you -

In several HTC WM phone devices, setting the option to vibrate on new mail doesn't work when the device is in standby. Is this by design, or a bug? An example device is the HTC Wizard.

If it's by design, please do something so that we can enable it, even if it's a reg entry. If it's a bug, well...

If the device would do a short vibe when new Direct Push mail is delivered, this would truly be close to a blackberry killer. As it is, it's 70% there.

re: Power to the System

Tom Bradley — Mon, 03 Jul 2006 11:59:05 GMT

Hi there,

As with John Wei, I'm also developing an application that requires the use of unattended mode. I've writtin a small test program based on your suggestion above, though I'm having a few issues.

The test program wakes itself up using CeRunAppAtTime every minute, sets unattended mode, sleeps for 10 seconds, sets the next wake up event, then unsets unattended mode.

1. When the device has woken up and entered unattended mode, the keyboard and touchscreen are active. An accidental press on a button or touch of the screen wakes the device up. Is there any way to fix this?

2. Sometimes, like once an hour, the device will wake up completely. Its as if the call to request unattended mode didn't work.

3. After a long time, say 3 hours, of waking up and sleeping, if I turn the device on I've lost the use of the touchscreen and have to soft reset before I can use it again.

I'm using a Symbol MC70 running WM5

Any help would be much appreciated.

Tom

re: Power to the System

tomb@ibcos.co.uk — Mon, 03 Jul 2006 12:35:33 GMT

In addition to my previous post,

I forgot to mention another anomaly I've been experiencing.

The first time my application wakes the device up and enters unattended mode, the call to PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE) does not suspend the device again. After the user idle timer expires, it suspends the device for me, then all following calls to PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE) work. I've tried a variety of ways of suspending the device, including the user idle timeout. All seem to exhibit the same behavior.

Cheers

Tom

re: Power to the System

MikeCal — Thu, 06 Jul 2006 23:06:29 GMT

(Assume everywhere below when I say "LCD off" I mean the touch screen is off too.)

John, the device is not behaving the way I expect it to. If the device is suspended, then CeRunAppAtTime will cause it to go into the Resuming state, which has the LCD off. When you put it into Unattended, it should leave the screen off.

It sounds like that device turns the screen on during Resuming. That is not our design. However, Symbol makes vertical devices intended for specific uses, and we sometimes allow verticals to act differently than our designs if the changes are needed by their specialized customers. It's possible that Symbol changed this behavior intentionally. You'll need to work with them to see.

For your second question, if the request to enter unattended mode failed, the device would suspend. It will only wake up completely if something tells it to. Maybe some other process is waking the device up?

For your third question, the touch driver is OEM specific. That's definitely something you'll need to work with Symbol on.

And, as for the question in the second comment, it sounds like something else is running on the device that has requested unattended. Unattended mode has a ref count that goes up every time someone requests unattended and goes back down every time someone releases it. The system won't suspend immediately if the ref count isn't 0. So, if something else is running that has requested unattended, then your requesting and releasing it won't suspend the system.

The ref count is cleared whenever the system wakes up from suspend, though. So if something has bumped it, either it ran right when your app did, or the system wasn't actually suspended when you started your app the first time.

Mike

re: Power to the System

Johan — Wed, 08 Nov 2006 14:54:40 GMT

Hi all,

We are using CeSetUserNotificationEx to wake up our application at certain points. Sometimes, not always, these notifications fails and we get the message "Notification error Can not execute program.exe". The program really exists so this is not the problem. We think that there are some problems waking the unit up if it is in deep sleep and that the Notification Manager will fail in this case. Anyone else out there that have the same problem?

re: Power to the System

odo — Fri, 19 Jan 2007 16:47:46 GMT

hi all,

we have the same problem using CeSetUserNotificationEx. under pocket pc 2003 our application runs without any problems. under wm5 the notification manager cannot execute our application, because it is looking for the application in the wrong directory, although the correct directory is assigned in CE_NOTIFICATION_TRIGGER. And sometimes the application cannot be executed although it is in the directory where the notification manager expects it.

anyone have an idea ?

re: Power to the System

Joel — Tue, 23 Jan 2007 20:14:25 GMT

Hi all,

I am using PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE) & PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE) around opening the serial driver. This works. If I turn the device off in the middle of opening the serial driver, the device goes into unattended mode and things progress nicely. The problem we are having is the power button acts strangely after we put the device in the unattended state, and requires 5 or so presses to turn the device on or off. From a user experience this is a big issue.

Any ideas?

re: Power to the System

MikeCal — Tue, 23 Jan 2007 20:38:57 GMT

Johan and Odo, I've seen the "can not execute program.exe" issue occasionally on my Nightly program. I'm running on a Smartphone (which can be fully shut off) not a PocketPC (which can suspend), and for me, it only happens when the phone was fully off when the device was supposed to run. Of course it only happens occasionally, so I don't have a good set of repro steps for it. I've assumed there was an issue during boot of the notification firing before the filesystem is finished loading. I don't have a good solution for it, though. Sorry.

Joel, the way the device is supposed to work is that when in unattended mode, a press of the power button should turn the device on immediately. This is handled by the OEM's keyboard driver calling a different power PowerPolicyNotify (this time PPN_POWERBUTTONPRESSED) whenever the power button is pressed. It's possible that the keyboard driver on your device isn't doing this correctly. Can you tell me which device it is?

Mike

re: Power to the System

Joel — Wed, 24 Jan 2007 01:42:37 GMT

Mike,

Thank you for your quick response. BTW, I appreciate your blog; it is helpful!

Regarding the device I presume yes, but I am waiting for permission from the project manager to release the information. That said and assuming you are correct that the keyboard driver is not working correctly, is there an easy way for our application to hook the power button on/off and issue our own PPN_POWERBUTTONPRESSED (or suspend for that matter)? A hack by any other name... I am hooking other hard buttons but as I recall, the method does not work for the power button.

FYI, when this device is in the unattended state it takes exactly 5 button presses to turn the device on if off, or off in on, and this behavior is not time based.

Joel

re: Power to the System

MikeCal — Wed, 24 Jan 2007 03:53:33 GMT

Unfortunately, any way to hook the power button would be OEM driver specific. The keyboard driver needs to tell us that the power button was pressed before we can tell your app that it happened. My guess at the current problem is that the driver isn't doing that in the first place.

One thing you can do to narrow the problem down is to have your app watch for one of the keys you CAN hook, and, when it's pressed, do:

PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0);

If that turns the screen on as normal, we will have a pretty good indication that if the keyboard driver were to do that things would work. If that also takes 5 presses, I'll have to ponder more what's happening.

Mike

re: Power to the System

Joel — Wed, 24 Jan 2007 17:58:44 GMT

Mike,

Thanks for your idea and it palyed out as you expected; pressing the 'ok' button turned the device on or off with one click. We will be forwarding the issue to the OEM.

The reason all this special case coding happened in the first place is that the OEM is loading and unloading the compact flash drivers on power up/down. What we are seeing is the drivers don't finish loading when powered off in the middle of loading/unloading (either by pressing the power button or by going back to sleep) and every so often, these drivers don't recover and will not make it to the PNP section or the registry when powered on, and consequently the cards do not work without a device reset. Your thoughts regarding?

One more request for the moment: Resetting the idle time to keep the device from suspending works as expected. Given the default is three minutes, can we programmatically change to something smaller (say 30 seconds) before we reset, and then change back to whatever the original setting was?

Joel

re: Power to the System

Joel — Wed, 24 Jan 2007 21:00:49 GMT

Mike,

Sorry about the spelling errors. It was early this morning.

The device we are using is the TDS Recon X running Windows Mobile 5.

Joel

re: Power to the System

MikeCal — Thu, 25 Jan 2007 00:08:52 GMT

Hi Joel,

I don't work with TDS, so if you're already in contact with them and they're receptive to your issues, that's a good path. In general, all they really need to do for the Hibernate issue is to replace whatever they're currently doing when the power button is pressed (I suspect they're sending a VK_OFF) with the PowerPolicyNotify.

The CF drivers issue is more complicated. The OEM has a number of places in the suspend and resume processes where they can control what's happening and how long things take. They should be making sure that their drivers fully unload/load. So, while the PowerPolicyNotify is certainly the EASIER fix, fixing the CF driver is the correct one.

I don't think I understand your idle time question. The default is 3 minutes, but the UI allows users to set it as low as 1 minute. For that reason, we suggest that apps call SystemIdleTimerReset every 30 seconds. That's guaranteed to be more often than the minimum idle time and has a good amount of room for slop. You could get away 45 seconds, and could probably get away with 59 seconds, but 30 seconds is definitely safe.

But I don't think that's what you're asking. Are you asking to programatically change the timeout value itself? If so, I'd need to know more about what you're trying to do. Are you worried about resetting the idle timer a few seconds before you finish what you're doing, leaving unattended, and then having the system stay awake for almost 3 minutes? That won't happen. The system suspends immediately after leaving unattended mode.

Mike

re: Power to the System

odo — Tue, 30 Jan 2007 11:59:55 GMT

hi mike,

thank you for your response !

i don't think that it only deals with the filesystem..

i changed the directory of the executable, but the OS still looks after it in the previous directory..

i also cleanbooted (factory settings) the device (it is a symbol mc9094 wm5) and got the same message by the OS !!!

odo

re: Power to the System

odo — Tue, 30 Jan 2007 12:07:58 GMT

hi,

where does the OS "save" the setting with the notification ? in the registry or somewhere else ?

odo

re: Power to the System

Sean Howarth — Mon, 12 Feb 2007 21:44:12 GMT

Hi Mike,

Thanks for the great blog.

We are using PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0) in our WM6 keyboard driver whenever the user presses the power button, and we're running into a problem when the power button is pressed twice quickly, the second time occurring before the device is suspended.

It appears that the PowerPolicyNotify call is an asynchronous notification to the Power Manager, and the second notification we're issuing appears to be processed after the device is resumed, resulting in unexpected behavior.

My question is, how should this situation be correctly handled?

Thanks, Sean

re: Power to the System

MikeCal — Wed, 14 Feb 2007 01:07:24 GMT

Sean, what kind of time are we talking about between the two presses? Is it a case of hardware debouncing being needed, or is it a user physically pressing the button twice quickly?

Is this an accurate description of what you're seeing?

1) Device is awake and the user presses the button twice quickly

2) Device goes to sleep

3) User presses the power button again

4) Device wakes up and then goes back to sleep

Mike

re: Power to the System

Sean Howarth — Wed, 14 Feb 2007 04:03:06 GMT

Hi Mike,

This is a case of the user physically pressing the button twice quickly (hardware debouncing has been disabled for the purpose of this test), and the situation is exactly as you describe. I should also mention that the keyboard driver calls PowerPolicyNotify once during the resume.

We're also able to reproduce the behavior with an application calling PowerPolicyNotify twice before suspend, with a small wait between calls.

I'm considering addressing this issue by flushing the PM policy notification queue during the keyboard power off handling. What are your thoughts on this approach?

Also, what's the recommended way for an application to suspend the device? PowerPolicyNotify, GwesPowerOffSystem, SetSystemPowerState, or something else entirely?

Thanks, Sean

re: Power to the System

MikeCal — Wed, 14 Feb 2007 21:29:04 GMT

Sean, flushing the PM queue is a dangerous action. It's possible that you'd throw out other things in the queue, like an application request to go to unattended, and break user scenarios like always up to date email.

I've talked with the Power Manager owner, and unfortunately, we don't have a good solution for you. We believe that if you send a PPN_POWERBUTTONPRESSED while the system is suspending then it will be queued up and run again when the system wakes up (as you're seeing).

I'd first verify with your customer that they find the "user presses the power button rapidly" feature to be compelling. There are probably a hundred different WM devices on the market that don't guard against this that are doing fine.

If your customer believes that this scenario is important, I guess my suggestion would be some sort of advanced debouncing on the power button. You could grab the tick count when you send the PPN and store it in a variable. When you go to send the next one, check to make sure sufficient time has passed. Have some guard value like 0xFFFFFFFF that means to allow the PPN no matter what, and set the variable to that value in the keyboard power handler. That way you can put a fairly large debounce time in and not have to worry about scenarios where the device does suspend and the user wants to turn it back on immediately.

Regarding applications suspending the device, please give me the scenario you're trying to implement there. There are few, if any, reasons for an application to suspend the device. The application will almost never know what the user really wants to do and will likely do the wrong thing. For instance, how will the application know that the user isn't watching a movie, or that always up to date email isn't syncing, etc?

The one valid place I've ever seen for apps wanting to shut the system down is unattended ones. For instance, if you have a app that needs to wake the system up every 5 minutes but only needs to run for a few seconds, you don't want the system to spend 3 minutes timing out only to start back up in 2 minutes. Unattended mode was designed for that situation and handles it for you. When the app leaves unattended mode, if nothing else is going on with the system, it will suspend immediately.

Mike

re: Power to the System

Greg — Sat, 17 Feb 2007 16:22:11 GMT

I have a problem with the message queue returned from a call to RequestPowerNotifications(mQue.Handle.ToInt32, PowerEventType.PBT_TRANSITION). Often the message returned from the message queue is not correct. The normal sequence of events when the ON button is pressed is an event with a “resuming” message followed an event with an “on” message. In the code below the ‘on’ message is sometimes returned without being preceded by a “resuming” event. Other times neither event appears to be returned (It could be that the “resuming” event is returned without being followed by an ‘on’ event). Also, sometimes the “resuming” message is returned when the Pocket PC is turned off.

Public Sub mQue_DataOnQueueChanged1(ByVal t As Object, ByVal e As EventArgs)

Dim bytes() As Byte

Dim msg As New CustomMessage

Dim rwr As ReadWriteResult = mQue.Receive(msg, 0)

Static Dim intCntr As Integer

If (rwr = ReadWriteResult.OK) Then

bytes = msg.MessageBytes

PwrHandle = New CE_SystemPowerState.PowerClass(bytes.Length, bytes)

Select Case msg.strSystemPowerState

Case "on"

MsgBox("intCntr = " & intCntr)

intCntr = 0

Case "unattended"

Dim intI As Integer

intCntr = 0

For intI = 0 To 30000

intCntr = intCntr + 1

If PwrHandle.PowerPolicyNotify(PwrHandle.PPN_Message.PPN_UNATTENDEDMODE, False) = False Then

Exit Sub

End If

Case "resuming"

If PwrHandle.PowerPolicyNotify(PwrHandle.PPN_Message.PPN_UNATTENDEDMODE, True) = False Then

Exit Sub

End If

Case Else

‘ Do nothing.

End Select

End If

End Sub

When the message sequence returned is correct (“resuming" followed by “on”) when the user turns on the Pocket PC a message box appears containing the text “intCntr = 30001”. Sometimes (especially after the program is started fresh) the message box has the text “intCntr = 0” which indicated that the “resuming’ message was not returned before the ‘on’ message. After turning on and off about 5 times then the “intCntr = 30001” message appears for about 10 on/off cycles. Then “intCntr = 0” again appears (or sometimes no message box at all) for a couple of cycles before text “intCntr = 30001” returns again for a number of cycles.

Is there any way to make the messages returned during power transitions more reliable?

re: Power to the System

MikeCal — Tue, 20 Feb 2007 00:30:46 GMT

Greg, my VB is really rusty, so forgive me if I'm missing something. But aren't you only incrementing intCntr to 30001 if the system is Unattended? If the system goes from Resuming directly to On without doing Unattended, wouldn't that result in intCntr still being 0?

Mike

re: Power to the System

Greg — Tue, 20 Feb 2007 05:09:54 GMT

Mike,

Thank you for your reply. You are correct, intCntr only increments to 30001 if the system is Unattended. Shouldn't the system go into Unattended mode each time the "resuming" event message is returned? Why would the system goes from "resuming" directly to On without doing Unattended if I catch the "resuming" event in a Select Case block and call PowerPolicyNotify(PwrHandle.PPN_Message.PPN_UNATTENDEDMODE, True)? When I step through the code,

If PwrHandle.PowerPolicyNotify(PwrHandle.PPN_Message.PPN_UNATTENDEDMODE, True) = False Then

always returns True.

What I do see when I step though the code is the value of msg.strSystemPowerState on the Select Case line does not always give the result I expect. When I press the power button to turn the device "Off": most of the time I get a "suspend" message but sometimes I get a "resuming" message and occasionally a "unattended" message. When the "unattended" message is returned then the wireless LAN light blinks while power to the display is turned off. Pressing the power button several times fixes the problem of being in unattended mode when the device is supposed to be suspended.

When I press the power button to turn the device on: most of the time the "resuming" message is first returned, followed by "unattended", and finally "on", and the msgbox appears with the text "intCntr = 30001”. Sometimes when I turn the device on the "on" message appears without being preceded by "resuming" and "unattended" messages. In this case "intCntr = 0" appears which is what would be expected if the "resuming" did not precede the "on" message. The only way the "unattended" message would appear (and "intCntr = 30001”) is if a "resuming" message is returned first because the unattended state is called in the code block under "resuming". If the power button is pressed to turn the device off and it goes into Unattended mode as stated above: if the device is turned on with an "on" event first then “intCntr = 30001” appears, where intCntr was set while device was supposed to be suspended but was actually in unattended mode.

Sorry if I'm a bit verbose in describing the problem. I could sum up by saying that RequestPowerNotifications message queue appears to intermittently return the wrong power event. I am using a P2PmessageQueue to handle the messages from the power system. I assume messages are retrieved from a P2PmessageQueue object in a first in/first out basis. If P2PmessageQueue returns messages in no particular order, or on a first in/last out basis, then this would explain my problem.

Thanks again,

Greg

re: Power to the System

MikeCal — Wed, 21 Feb 2007 22:04:52 GMT

Greg, your device isn't behaving the way I suspect. I believe there is an unattended app that is running more frequently than normal.

On a typical suspended device, if you press the power button it will go from suspended to Resuming, and then from Resuming directly to On. There's no reason for it to go to Unattended in that case.

If the system wakes up due to an unattended app running, you'll typically see it go from suspended to Resuming, and then go to Unattended from there. If, while the unattended app is running, you hit the power button, it will go to On.

It's pretty unusual for the system to go from suspended to resuming to unattended to on all in one press of the power button. Usually it's either already in unattended when you press the power button or it doesn't do unattended at all.

On the suspend case, there's no guarantee that your app will run before the system suspends. The system doesn't notify apps before suspending because it doesn't want apps to have the power to slow down the suspend. So you're more likely to see the wake up than the suspend.

I'm pretty confident in the message queues. They're used in a bunch of places throughout the system and work there. I believe what they're telling you is happening is really happening. I just don't understand why your system is working the way it is. What unattended mode apps do you have on the system? The two main ones that come with it are active sync when doing "always up to date" email and calnot/clocknot which run briefly at midnight. There are some OEMs that do other things with unattended as well. For instance, the Palm Treo uses unattended pretty significantly and frequently uses it if their hardware detects certain situations at resume. Maybe you have something similar?

Mike

re: Power to the System

Jozsef Zsido — Fri, 13 Apr 2007 15:33:50 GMT

From what I know, the PowerPolicyNotify API manages an internal counter. Can this value be obtained from somewhere? (API, registry)

I have trouble maintaining the Palm Treo 700w in the unattended state. It behaves like another process is reverting the effect of the PowerPolicyNotify and my application enters the suspended state.

re: Power to the System

MikeCal — Mon, 16 Apr 2007 23:57:47 GMT

Jozsef, are you calling SystemIdleTimerReset() every 30 seconds? Unattended protects you against the user hitting the power button, and it allows you to wake the system up and do work without turning the screen on, but you still have to keep the system from timing out due to inactivity.

We didn't want an app to call the PowerPolicyNotify, then crash, and lock the system on forever.

Mike

re: Power to the System

jaigarru — Sun, 13 May 2007 18:49:36 GMT

Greg,

How do you make to get aware of any power change with RequestPowerNotifications in VB .NET? I want to create a queue to know when the power off button of my PDA is pressed, but I don't know how.

Could you pass me the code (with as more details as possible, because all information I've find is in C and I can't understand it).

Thanks

re: Power to the System

Mitrich — Wed, 27 Jun 2007 17:21:55 GMT

Hey buddy how to make my app not to go blackscreen? on both wince 4,5,6? I mean I use keybrd_event(..) every 10 seconds, but it doesnt work on wince 4. Also I dont know the name of the driver (BKL1, BKL2, BKLN...) so is there an easy way to tourn off for the time my app is runing this powersaving mode?

re: Power to the System

MikeCal — Mon, 02 Jul 2007 19:52:27 GMT

In Windows Mobile, we require that the backlight driver be named BKL1:, so you should be able to SetPowerRequirement on that. Sorry, but I can't remember if the power infrastructure that relies on was available version 4.

Mike

re: Power to the System

Mark C — Sat, 14 Jul 2007 07:07:09 GMT

I'm particularly interested in the ScreenOff state. I think a stand alone utility that toggled the ScreenOff state would be an excellent power saver for my Samsung sgh-i607 smartphone, or any smartphone for tht matter.

I realize that Media Player offers this functionality, but Media Player has to be running in order for it to work. And, that workaround becomes ineffective when I connect to the smartphone with Active Sync and use an application called Pocket Controller, which allows me to fully control my smartphone from my PC. Once I connect through Pocket Controller and want to navigate away from Media Player into something else, all the lights come back on, and that becomes annoying as well as a battery drain. Particulary if I am connected to the device via Bluetooth.

I'm not a programmer. Could you be so kind as to point me in the right direction, or even post the code C# needed to toggle ScreenOff state? It would be great to have this utilty that could be assignable to a hardware key, so that it could be easily toggled on/off.

Thanks!

re: Power to the System

Trevor Morris — Tue, 17 Jul 2007 17:07:25 GMT

I can't yet use the WM5 APIs, and have an application that requires the system to stay on, in order to receive wireless notifications. I do turn the screen off, but have to periodically call SystemIdleTimerReset().

Which of these is the best way to delay, so that the CPU can go idle:

1) Create a thread & Sleep.

2) Create a system event to call my app.

3) Create a timer.

4) Something else?

re: Power to the System

MikeCal — Wed, 18 Jul 2007 20:18:28 GMT

Mark,

I'm not sure ScreenOff will really do what you want, though. On smartphone (Your blackjack is a smartphone) pressing any key will turn the screen back on. Then you'll need to invoke your program to turn it back off again. You might find that invoking keylock works better. When the device's keys are locked, the screen turns off automatically after 3 seconds.

If you want to do ScreenOff, though, here's the code you need.

I don't think there's a C# wrapper for SetSystemPowerState, but this is the C++ for turning off the screen.

SetSystemPowerState(NULL, POWER_STATE_IDLE, 0);

If you want to turn the screen on, replace POWER_STATE_IDLE with POWER_STATE_ON.

If you want to pInvoke it, this should work:

[DllImport("coredll.dll", SetLastError=true)]

static extern int SetSystemPowerState(string psState, int StateFlags, int Options);

POWER_STATE_IDLE is 0x00100000

POWER_STATE_ON is 0x00010000

I hope this helps,

Mike

re: Power to the System

MikeCal — Wed, 18 Jul 2007 20:22:33 GMT

Trevor, the methods you suggested are pretty equivalent. However, how long do you plan to keep the system awake? Keeping a PocketPC from suspending can have a pretty significant effect on battery life. If you're going to do it for a few minutes, it's probably not an issue. But if you're planning to keep the system on all the time, you're likely to cause trouble for your users. What kind of notifications do you need to get? Would it be possible to have the notification itself wake the system up so that your app can let it sleep?

Mike

re: Power to the System

Mohammed — Fri, 20 Jul 2007 12:05:44 GMT

hi ,

In Palm Treo , the power key is mapped to call end key , when the call end/Power key is pressed the screen freezes up . how it could be handled . Is it in an unattended state

re: Power to the System

Trevor Morris — Mon, 06 Aug 2007 16:01:33 GMT

MikeCal wrote:

>What kind of notifications do you need to get? Would it be possible to have the notification itself wake the system up so that your app can let it sleep?

The notifications are coming through a WiFi alert. The user of the device is receiving an important message, whose time can't be predicted. Is there a way to have a PocketPC wake up on this sort of event?

re: Power to the System

MikeCal — Tue, 07 Aug 2007 00:03:30 GMT

Unfortunately, no. The WiFi stack runs on the main CPU, and that CPU is off when the system is suspended. So you can't wake the CPU with a WiFi notification.

Apps that need to get asyncronous WiFi communications (ie VOIP) either need to keep the system on all the time, or be run on a Smartphone instead of a PocketPC. Smartphones already keep the system on all the time, but are tuned to do it well.

Mike

re: Power to the System

Ryan — Thu, 09 Aug 2007 02:29:22 GMT

Mike,

I'm developing a .NET CF 2.0 app to run on a WM 5.0 PDA. I want to do some processing in the middle of the night, and my idea was to use the transition from "suspend" to "unattended" to do this.

By logging the power events that the RequestPowerNotifications gives me, I see that at midnight the device always wakes up for at least 15 seconds and sits in "unattended" mode.

I would like to piggy back on this wakeup and simply perform my processing at that time. Do all WM 5.0 devices wake up in this manner? Or are there situations the device does not go into unattended mode in the night?

Thanks,

Ryan

re: Power to the System

MikeCal — Mon, 13 Aug 2007 23:12:25 GMT

Hi Ryan,

Windows Mobile wakes up at midnight for two special processes: CalNot and ClockNot. One updates Calender Notifications and one does Clock Notifications. One runs every night at midnight and one runs every Sunday at midnight. I can't remember which is which. (-:

These processes are on every Windows Mobile device, but it's not guaranteed that they will always be. In some future version we could concievably change when they run, or get rid of them completely.

There is a much safer way to do what you want. If you call CeRunAppAtTime you can set the system to wake up and run your application at whatever time you'd like, including Midnight. If you do that, you can run at the same time Cal/ClockNot runs, but continue to work even if we change them in the future.

Mike

re: Power to the System

Tim — Tue, 21 Aug 2007 22:55:54 GMT

Hi Mike,

Thanks for all your posts. They're great. Here's my question: Does the CPU clock speed mode that you can set under Settings->System->Processor (WM5) have anything to do with these power states?

We're using a PPC (FSC PocketLoox) as a dedicated device and want to tweak the CPU clock speed mode setting programmatically, but can't figure out how. Can't seem to find any documentation on what this corresponds to. Clearly this is processor dependent. Is this an OEM-specific thing?

Thanks!

Tim

re: Power to the System

roozbeh — Thu, 13 Sep 2007 19:12:57 GMT

Hi Mike,

I have a program that shows a notification when an sms is recieved.butafter some seonds-i guess you said 6 seconds-it turns off device again.

My program load a dll which loading it take around 6-7 seconds-becouse on loading it does some other things too-.

So how can i prevent system from getting back into sleep mode.

I think the calling SystemIdleTimerReset on another thread solve might the problem.but how much the interval should be?

and also i read somewhere that keylock programs interfere with this and when keylock is on,calling this wont keep system alive..

so is there any solution?

re: Power to the System

roozbeh — Thu, 13 Sep 2007 19:13:15 GMT

Hi Mike,

I have a program that shows a notification when an sms is recieved.butafter some seonds-i guess you said 6 seconds-it turns off device again.

My program load a dll which loading it take around 6-7 seconds-becouse on loading it does some other things too-.

So how can i prevent system from getting back into sleep mode.

I think the calling SystemIdleTimerReset on another thread solve might the problem.but how much the interval should be?

and also i read somewhere that keylock programs interfere with this and when keylock is on,calling this wont keep system alive..

so is there any solution?

Power settings/CommonTime Mnotes

Bob Walker — Tue, 02 Oct 2007 16:22:14 GMT

Anyone out there familiar with CommonTime mNotes?!

I have a question relating to our corporate PDA solution - M3100s (aka HTC Hermes) ROM version 2.11.61.1 running Windows Mobile 5 with CommonTime Msuite v.4.3.966 hooking into our Lotus Notes email for push etc

Now...regarding Push. My understanding is as follows: The device registers with mnotes notification server "hello, I'm here"...if any new mail is waiting then mnotes will push it out to the commontime client on the device. So far so good. I'm also under the impression that if the PDA is 'asleep', then it is no longer bothering to regsiter its self with the mnotes notification server, and therefore receives no push mail. To combat this, in the mnotes client there is a 'Device wakeup Period' slider which specifies a how often the device wakes up from its slumber to go regsiter with notification server. By default, this is set on the slider to happen every hour.

So what power state constitutes 'asleep'in this instance? At what point does the PDA switch from receiving a new mail pretty much instantly...to being asleep and the device having to drag itself out of bed to go and handshake with the notification server to pick up new mail?!

Bob

re: Power to the System

MikeCal — Tue, 16 Oct 2007 02:54:08 GMT

Sorry for such a late response. It appears that I missed these questions.

Tim:

Processor speed is entirely an OEM thing. There's nothing inherent in the OS that sets processor speeds, and anything regarding these speeds would be separate from the device states. It's possible that the OEM choose to change rates at various states, but I wouldn't expect that. It's more likely that they do it based on CPU idle than user inactivity.

roozbeh:

It sounds like you're being hit by the Resuming state. SystemIdleTimerReset doesn't affect the resuming state. If you search this page for "PPN_UNATTENDED" you'll find a comment where I explain what you need to do.

Bob:

I'm sorry, but I'm not familiar with mNotes. I'm guessing, however, that the "asleep" you're talking about is whenever the system is suspended. If you go into the Power control panel, you'll see words to the effect of "on battery power, suspend if the device is unused for 3 minutes." You can change the number of minutes there. Whatever you set, if you don't interact with the device for that long it will suspend. It will also suspend if you press the power button.

Mike

re: Power to the System

Ian — Fri, 02 Nov 2007 19:14:04 GMT

Is it possible to wake the device from sleep by pressing the screen not by button?

So, when the device is standby (or screen off), user could press the screen to make the screen on again?

Thank you.

re: Power to the System

MikeCal — Tue, 06 Nov 2007 00:45:02 GMT

Ian, it is possible for an OEM to make hardware that acts that way, but I haven't seen any do so in a very long time. The general problem with that concept is that the device will be touched while the device is in your pocket and that will drain your batteries. The last device to enable this had a clear plate that went over the screen to keep it from being touched when you didn't want it to be. Needing to move the plate aside was worse than needing to press a power button.

Mike

re: Power to the System - BlackJack, Smartphone idle mode, and WMP

Jason — Wed, 07 Nov 2007 02:52:11 GMT

Mike,

On July 18, you mentioned how Smartphone (BlackJack specifically) keypresses turn the screen on if it's been turned off via POWER_STATE_IDLE.

We'd like to keep the screen off in these circumstances, and receive the key messages to our application. When the user presses the correct key, we'd like to turn the screen back on. This happens for Windows Media Player on Smartphone - you toggle the screen and it stays off.

We've tried looking for PBT_TRANSITIONs to POWER_STATE_ON from our queue, and then either turning the backlight off via another POWER_STATE_IDLE call, but then we don't get any key input.

Watching what WMP does, when you press a key with the screen off, the system doesn't enter into any different mode - it stays idle, and the keys get to WMP somehow.

How can this be achieved on Smartphones?

re: Power to the System

Jason — Wed, 07 Nov 2007 19:08:57 GMT

Mike,

After doing more research, it looks like (at least on the BlackJack) the keyboard driver (keypad.dll) has "WMP for Mobile Devices" hardcoded to get special treatment. If the foreground window class matches, then the screen stays off.

Unfortunately this string is hardcoded in the driver, and not the registry or anywhere else, so to fake it, we'd have to change our window class (tested, and it works) which isn't feasible.

We actually ran into another (unrelated) issue with the BlackJack specifically - their wheel messages weren't being sent (that is, VK_UP/DOWN without the VK_ROCKER) to normal applications (to get the fancy listview handing for wheel vs. dpad). Their driver in this case looks for the MSStart (and other application classes).

You may want to institute some guidelines for OEMs regarding this.

re: Power to the System

Hrissan — Thu, 15 Nov 2007 22:10:48 GMT

Thanks for the article!

But what a mess those power-related problems! I never heard of anything designed so bad, sorry M$ guys, you do not have any idea how the good software is made. I see different hard-coding in OEM drivers every day. They do it not because they are stupid, but because they have no other way to get behavior they need... And we are not speaking about rocket science here.

And now we need that special behavior in my application, but we cannot hard-code it into driver! IWe need it to work on hundreds different (but essentially the same) pieces of hardware... No way.

You can censor my comment off, but Windows Mobile applications do not get any better from this. :(

re: Power to the System

MikeCal — Tue, 20 Nov 2007 20:33:44 GMT

Jason, we certainly didn't expect OEMs to hardcode app names into their driver. )-:

Can you tell me more about what your app is trying to do? What is the scenario where you want the user to send your app keypresses without him seeing the screen? In general, if I'm interacting with the device I expect the screen to be on. If I'm not interacting with the device, I lock the keypad.

Mike

re: Power to the System

Jason — Tue, 20 Nov 2007 22:12:29 GMT

The app in question is our media player product named Pocket Player, www.conduits.com/products/player, and users often want to keep the screen off when they are controlling the device. Media players would want this functionality; I'm not sure off-hand for other use case scenarios. It's the "ScreenOff" power mode above, and works on all devices except those that hardcode WMP in their driver.

"Interacting with the device" could be limited to just pressing Action to pause playback but unfortunately the screen turns on after any keypress, unless we fake our window class name.

re: Power to the System

MikeCal — Thu, 22 Nov 2007 09:09:31 GMT

Jason, you have us scratching our heads here. The usage you're describing is exactly what the "ScreenOff" state was designed for. I checked with the owner of Power Manager today and he checked the code to be sure. The only way out of ScreenOff is someone calling an Api or someone hitting the power button. So it SHOULD be that if you put the system into ScreenOff, your users should be able to press buttons while keeping it off (so long as none of them are the power button).

Does what you're seeing happen on all devices, or just the Blackjack? There's an API they can call that forces the screen on. I wonder if they're doing it for every keypress or something.

Mike

re: Power to the System

Jason — Thu, 22 Nov 2007 21:12:01 GMT

Mike,

My comment from November 6 was when we were scratching our heads too :) By November 7, we had figured out the issue: it's a BlackJack only problem and is caused by the keyboard driver. The problem doesn't happen on other Smartphones.

It seems that the WM OEM kits should include some keyboard/power state test harnesses for the OEMs, and guidelines to never hardcode app class names into drivers. The BlackJack forcibly turns on the screen unless the current app is WMP. As mentioned before, the driver is also defective in that it never sends the VK_ROCKER/VK_DPAD notifications unless you are on the MSStart window (or an Open Picture dialog), hich helps with navigating listviews with a scrollwheel.

re: Power to the System

Stefan — Tue, 27 Nov 2007 00:18:14 GMT

Mike,

I have a piece of code that uses CeSetUserNotificationEx to run applications at a given time. The code works fine on Smartphone, but on PocketPC it does not wake up the device, but rather queues up all notifications and runs them when the device is manually woken up.

What would be the correct way to get this working this on the PocketPC. I have seen samples that suggest that CeSetUserNotificationEx is the way to do it on PocketPC but for some reason it does not work(The Pocket PC device is AT&T Tilt or HTC TyTn II if that matters).

re: Power to the System

MikeCal — Tue, 27 Nov 2007 21:52:54 GMT

Stefan, the correct way to do what you're describing is to use CeRunAppAtTime. That will launch your app at the given time, and will wake up the PocketPC to do it (if necessary).

Mike

re: Power to the System

skyntchev — Sun, 02 Dec 2007 16:13:36 GMT

Thanks Mike,

Unfortunately, CeRunAppAtTime does the same thing - if the device is awake both CeSetUserNotificationEx and CeRunAppAtTIme work correctly. Once device is asleep they "queue" the notification(s) and run them once you wake up the device. I know that they are scheduled correctly and they run because the moment you press the power button everything executes as planned. Do you have any idea why would that happen? Can it be device specific (again the device is HTC Kaiser, TyTn II, AT&T Tilt).

re: Power to the System

Jason — Sun, 02 Dec 2007 17:27:21 GMT

Stefan,

It might be that the device is in Unattended mode, but is indeed running the application. This gets around the longstanding "device wakes up at midnight" problem.

Try calling SetSystemPowerState(NULL, POWER_STATE_ON, 0) in your WinMain and see what happens.

re: Power to the System

skyntchev — Tue, 04 Dec 2007 23:04:25 GMT

Thanks Jason,

I did quite a bit of experimentation and this is what I found. On Pocket PC, both CeRunAppAtTime, and CeSetUserNotificationEx both do wake up the device and do run correctly, IF the application they are trying to start is a native C++ app. The application I am trying to start is actually a .NET CF application. In this case generally what I see is instead of starting my app, the system queues my scheduled events and starts them when the device wakes up.

But here is another bizarre behavior. If I happen to have any (even completely unrelated) .NET process already running when device when to sleep in vast majority of cases (but not always) my app starts correctly at the scheduled time. I even tried set a native app to start my .NET app (both using CreateProcess and ShellExecute) but the result is still the same – all gets queued up for wakeup.

My current theory is that there is may be some time interval in which the application has to start and if it takes longer than that, the start is aborted and the task is queued for execution on wakeup. Does this make any sense?

re: Power to the System

ayyrk — Tue, 18 Dec 2007 05:58:57 GMT

Hi, I have a WM5 GPRS socket application that immediately tries to reconnect when the stream closes. I think the stream is closed on the client side when the value in "Turn off the device if it has not been used for xx minutes" is reached.

I trace the socket communication on the server side and see the device disconnect and immediately reconnect. So it is never really suspending. It goes into a state where the screen is off and all buttons, except the power button, are disabled. But I can see on the server that it is continuously disconnecting/reconnecting.

What do you think is preventing the device from suspending? Could it be something like a "wake on GPRS" setting?

re: Power to the System

Hezi — Sat, 26 Jan 2008 23:02:04 GMT

I have a WM5 application that needs to periodically check information from the RIL interface (say every 3 or 10 seconds).

Currently, if no user input is entered the PPC would fall into the idle state (not suprisingly), thus stopping the application.

I can use a few minutes timer and invoke the CeRunAppAtTime (for the same application) but am not sure this is the best way to revive the application.

What would you suggest?

BTW- I use C#

re: Power to the System

std.denis — Wed, 30 Jan 2008 11:20:09 GMT

Hey Mike,

I'm glad that I found sucha great blog and I've got a several questions for you :)

1. Could you tell me, please, what WM's thread scheduler do when it has nothing to do? For example, all threads are in an awaiting state. I'm almost completely sure that it is not using "while( no_new_external_events ) {}" to spend that "vacation" time.

As I remember my university course the x86 has HLT command to make CPU freeze until an interrupt occur. Does WM use the same feature of CPU's it running on?

Maybe it is not a responsibility of your team, but maybe you know how it done by OEMs in certain commercial devices.

2. What is the best way to get current CPU's utilization? There's no GetSystemTimes on CE platform. I found idea to use CreateToolhelp32Snapshot + Thread32First/Next + GetThreadTimes. But that enumeration could be interrupted by thread switch, so we could get a mistake. Isn't it?

Thank you,

Denis Stanishevskiy

re: Power to the System

Faiyaz — Mon, 04 Feb 2008 16:06:50 GMT

I am shutting down a Psion Device (Win CE 5.0) using the following calls -

FileSystemPowerFunction(1);

PowerOffSystem();

What api should I call to turn off the Keyboard backlight?

Thanks

re: Power to the System

Hujer — Mon, 11 Feb 2008 15:44:12 GMT

I have nearly the same situation as "Hezi".

I have a WM5/6 PPC application that needs to periodically check information from the WM registry.

Currently, if no user input is entered the PPC would fall into the sleep mode, thus stopping the application.

I can use a few seconds/minutes timer and invoke the CeRunAppAtTime (for the same application) but am not sure this is the best way to revive the application.

What would you suggest?

Please answer.

re: Power to the System

Confuzzled — Fri, 14 Mar 2008 17:41:43 GMT

What exactly is the difference between idle and useridle?

SetSystemPowerState(NULL, POWER_STATE_IDLE, 0);

SetSystemPowerState(NULL, POWER_STATE_USERIDLE, 0);

re: Power to the System

Alex — Fri, 16 May 2008 20:11:28 GMT

well, i think taht u can help me. When I turn off button of my device (G-smart), GSM signal down, and I dont receive callas and sms. This device dont have rom upgrade anymore (out of production). Any idea for solution?? arovaris@hotmail.com

re: Power to the System

mohan_m — Wed, 04 Jun 2008 08:55:17 GMT

I have target system (WinCE 5.0) in which Suspend/Wakeup works if the WinCE GUI Shell is included on PB OSDesign.

Without the WinCE GUI shell, the system always does a Cold Boot start. Any thing I should look for.?

re: Power to the System

selmaguzel — Wed, 18 Jun 2008 16:00:53 GMT

Hi,

How can I turn the screen off in c#?

Thanks.

re: Power to the System

selmaguzel — Thu, 19 Jun 2008 10:01:06 GMT

Hi,

Firts I must say that I suppose

POWER_STATE_IDLE mode is not valid for my sbc:arm9 based qq2440.Because when i use POWER_STATE_SUSPEND,

the system replies,but using POWER_STATE_IDLE i don't get result as screen off.

Now, my question is how the system gets through the POWER_STATE_ON state when a user touches the screen again.

Namely i should ask how the system gets events when it is on suspend mode?

Thanks in advance.

re: Power to the System

selmaguzel — Thu, 19 Jun 2008 16:30:46 GMT

Hi,

In fact i want to set all the things from platform builder, namely the time for getting through the screen off mode and then when user touches the screen again on mode.

Is it possible?

I suppose it can be if i set somethings in the source code of the pm driver or the PWRBTN_PCF driver(the pm driver in the sbc's bsp)?

Thanks in advance.

re: Power to the System

Jim Peternel — Fri, 27 Jun 2008 20:01:11 GMT

I'm working with a USB device connected to a WM 5.0 terminal. I've found that the terminal does not consider USB traffic when determining if the terminal is idle. So what happens is, I'm sending data in thru the USB port and the terminal goes to sleep. I've not found the PowerPolicyNotify to work for this case. I also can't seem to get the PPN(false) call to work. It seems to hang up.

[DllImport("coredll.dll", CharSet = CharSet.Unicode)]

public static extern bool PowerPolicyNotify(int dwMessage, int dwData);

bool bStatus = PowerPolicyNotify((int)PPN_Message.PPN_UNATTENDEDMODE, 0);

re: Power to the System

Marco — Thu, 06 Nov 2008 21:43:05 GMT

I'm developing a WM 6.1 device and my power button device driver calls PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0);, so the device normally goes to suspend and when the device is in the ScreenOff state its lcd/backlight turns on.

I'd like to add an optional behavior to my device through a dedicated configuration in the user interface.

That is I'd like that optionally pressing the power button it puts the device into the ScreenOff state instead of the Suspend state.

Do I have to change my power button device driver or does it exist an alternative way?

does a registry key exist to get this type of behavior?

How can I associate the power state transitions (i.e. from On to ScreenOff) and the power events (i.e. like power button pressure) ?

thank you!!

Marco