Wake from Modern Standby

We have an USB fingerprint sensor and our customer demands it can wake computer from sleep. User touches the sensor and the computer is awaken. So I assigned Sx wake settings and everything works as expected. Except… computer with AoAc support which is unfortunately the target one. Sleep doesn’t put system to S1 or S3 state as usual but it remains in Modern Standby, Connected Standby or whatever is the current fancy name for S0 sleep. I don’t even have an idea how it should work there. It seems from device point of view it looks like selective suspend, the device is put do D2, wake is armed and when user touches the sensor, it generates remote wakeup event as usual and the device state switches to D0 for a while. But it doesn’t have system wide effect i.e. the display stays turned off and there is no visible effect for an user. Instead of keypress or mouse move which turn the display on.

So my question is: is there a way how to make user visible behavior the same as for wake from Sx?

We’re using UMDF2 driver and Win10 19H1.

Hi Michal,
I recently encountered similar issue with a customer system using Modern Standby. In my case there appears to be a system issue. We plugged a standard USB mouse into the system and had similar failures to wake the system from the mouse. You might try the same test to confirm the system wakes properly. You said keyboard/mouse woke the system, but if the keyboard/mouse is integrated it may not use USB or might give a clue to the issue if you compare the power settings between your device and the keyboard.

Eric

Hi Eric,

I tried it with USB mouse and it works. Even “better” than usual, mouse move awakes it, not only button press. I guess it is because mouse generates input events which is what wakes up the display. Keyboard the same. But our sensor doesn’t generate such events.

Well, I’d really like to know how it is supposed to work :slight_smile:

Michal

1 Like

PoSetPowerRequest, PowerRequestDisplayRequired?
p.s. and in userland it is as simple as calling SetThreadExecutionState

It is UMDF driver to SetThreadExecutionState() could work but when to call it? It shouldn’t be called after every change from D2 to D0 as it is normal transition from selective suspend which can occur in many different reasons. It should be only called in this specific scenario. Well, I see there is WdfDeviceGetSystemPowerAction() and if it returns something meaningful here, it could be used for the decision.

Still I’m not sure if the driver is suppossed to do something like this and I’m afraid it can cause more harm than good… IMO this is something what should OS handle itself similarly as for Sx → S0 transition.

Opinions?

The whole colossal mess that is Modern Standby requires lots of super-tight systems integration. And I agree with Mr. Vodicka: You’re not supposed to have to do anything special. You wake, the system wakes, the display wakes. It’s all under the control of the “power manager” these days.

So, can finger printer readers wake the system and turn in the display? Yes, they are supposed to be able to do that. Does it actually work? I have no idea. I don’t even know where to look anymore, to be honest.

From Windows 8 and onwards, the mysteries of evolving AOAC power management have been short on documentation and in some cases, even shorter on good insight and architecture. We got PEPs, PoFx with F-States, then we got performance states (not P-States, cuz those are something different), then Dfx and DDRIPS and device S4, and who knows what else.

All I know is I’m confused, and I feel stupid when I can’t answer a simple question like the one in this thread.

Peter

I don’t even know where to look anymore, to be honest.

That’s exactly my problem.

All I know is I’m confused, and I feel stupid when I can’t answer a simple question like the one in this thread.

I feel stupid when I have to ask such a question… Well, I hope somebody from MS can shed light on this.

@“Peter_Viscarola_(OSR)” & @Michal_Vodicka-2
I feel better now. I kept looking at the “documentation” on the DFx and Modern Standby stuff and thinking I was missing something obvious. Maybe @Doron_Holan, the MSFT person I think of when USB comes up can help or at least point us to the correct person?

/rant

Much of the problem with Windows these past few years comes down to one thing: Too much implementation, too little architecture. Notice I didn’t say “design”… I said “architecture.”

Creating point solutions to specific problems is great, but not a substitute for creating an overall, well thought out, approach. Clever though many of the newly devised solutions are, they are not necessarily architected.

Architecture. It’s MIA in Windows these days. Has been for a while, to be honest.

/end rant

Peter

Look at this issue.
Perhaps, a Windows bug. There’s a workaround.
– pa

Interesting, it could explain the observed behavior. Thanks.

I believe workaround works as mouse move turns display on but I’m NOT going to simulate mouse movement from driver. No way. Also, driver runs in the context of the service which is noninteractive so it may not work there.

In the meantime I played with it and found SetThreadExecutionState(ES_DISPLAY_REQUIRED) has no effect which can be related to this bug. Anyway, I’m unable to distinguish D2 → D0 transition from standard wake from selective suspend as WdfDeviceGetSystemPowerAction() always returns PowerActionNone when in S0 sleep.

I guess I’m going to give up and tell the customer we have everything right and it is MS fault it doesn’t work.

BTW, selective suspend timer seems to be slower in S0 sleep. It takes 2-3x more time in this state till the device is suspended again after wake from finger. So finger touch has no visible effect but drains more power. Makes sense :wink:

@Michal_Vodicka said:
It is UMDF driver to SetThreadExecutionState() could work but when to call it?
As workaround - after any [successful] reading of fingerprint probably.

First, as I wrote before, it doesn’t work (probably because of the bug Pavel mentioned) so the rest is a bit academic.

Finger detect and finger scan are quite different disciplines. The former is just a signal which is handled by hardware. Easy, fast and almost no latency. The latter involves non-trivial amount of data transferred and software processing. Complicated, slow and latency in hundreds ms at minimum. Well, there are two kind of fingerprint sensors. Smart and cheap. Smart ones can process whole image internally rather fast and invoke remote wakeup only if there is a good finger. They’re better in all aspects and mainly more secure but customers for some reasons which are beyond my understanding prefer cheap ones which provide raw data and the image processing is done at the host side. It is also our current case. In addition, it’d involve rather signifficant driver redesign because normally it reads finger only if there is an active request from an application (including Windows logon). There is none when computer sleeps. In turn, a lot of work and for what? For the feature which works well with standard sleep but doesn’t with “modern” one. Rather superfluous and maybe even annoying feature, IMO.

@Michal_Vodicka,
What PreviousState do you get in your EVT_WDF_DEVICE_D0_ENTRY callback?
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdfdevice/nc-wdfdevice-evt_wdf_device_d0_entry

You might also compare the power options for the tree down to your device. For this i’ve recently been using usbtreviewer Which is based on usbview but has some nice added features. On really nice thing in the test report is this table for each host controller.

        -------- USB Hostcontroller Power States Info ---------
SystemState              : S0    S1    S2    S3    S4    S5    
HcDevicePowerState       : D0    --    --    D3    D3    --    
HcDeviceWake             : D3    D3    D3    D3    D3    D3    
HcSystemWake             : S3    S3    S3    S3    S3    S3    
RhDevicePowerState       : D0    D3    D3    D2    D2    --    
RhDeviceWake             : D2    D2    D2    D2    D2    D2    
RhSystemWake             : S4    S4    S4    S4    S4    S4    
LastSystemSleepState     : S4    S4    S4    S4    S4    S4    
CanWakeup                : no    no    no    yes   no    no    
IsPowered                : no    no    no    yes   no    no    

Eric

As an aside, I’ve also recently been using UsbTreeViewer and have pointed some of my clients to it. Very nice utility.

Peter

1 Like

What PreviousState do you get in your EVT_WDF_DEVICE_D0_ENTRY callback?

I haven’t checked but I’m almost sure it is D2. Why?

On really nice thing in the test report is this table for each host controller.

Nice. I was using some older version and didn’t know about it. Thanks for the tip.

As an aside, I’ve also recently been using UsbTreeViewer and have pointed some of my clients to it. Very nice utility.

Yes, I’m using it almost every day. Great improvement of the original DDK example.

What PreviousState do you get in your EVT_WDF_DEVICE_D0_ENTRY callback?
I was hoping it would be different for wake from selective suspend vs D2->D0.

I can check but I see no difference so far. Well, the one I already mentioned. Returning to sleep takes 2 - 3x more time than usual i.e. SS idle time.

Anyway, what would you expect? The device has to be in D2 for wake IMO.

Ok, now i have little time to dig into the problem.

Also, driver runs in the context of the service which is noninteractive so it may not work there.
First, as I wrote before, it doesn’t work (probably because of the bug Pavel mentioned) so the rest is a bit academic.
In the meantime I played with it and found SetThreadExecutionState(ES_DISPLAY_REQUIRED) has no effect which can be related to this bug.
No, it doesn’t work because you run your request from non interactive process (and pointed to this yourself!). And after your know answer it becomes obvious why it is not BUG. And yes, solution is very simple - run helper .exe as interactive process and make request from it.

I guess I’m going to give up and tell the customer we have everything right and it is MS fault it doesn’t work.
I would not like to be your customer…

And yes, solution is very simple - run helper .exe as interactive process and make request from it.

Nope. It is not driver job.

In the meantime we found OS handles it. Originally we tested it with no finger enrolled but once there is at least one finger enrolled, it starts working. In this case when OS is to put to Modern Standby, it switches to logon screen and logon sends finger capture request to the driver. On completion (wake) it processed the finger, turns on screen and logs on or displays info about bad finger to user.

Well, it even makes sense to my big surprise :wink: The only problem is it isn’t documented at all. Also, is continues this way even when all fingers are deleted which doesn’t look correct to me but I can live with it.

I would not like to be your customer…

That’s OK. I wouldn’t like to have customers who demand a functionality which doesn’t belong to the driver :wink: