Michal,
In addition to the other stuff that I told you already on this thread, you
might want to consider registering for notification when the screen turns
off. Treat that as an appropriate time to mark your device as unnecessary,
thereby letting it fall asleep.
To find out when the screen is off, register a callback using
PoRegisterPowerSettingCallback, passing in GUID_CONSOLE_DISPLAY_STATE.
Jake Oshins
Windows Kernel Team
This message offers no warranties and confers no rights.
“Vodicka, Michal” wrote in message news:xxxxx@ntdev…
I just made few experiments and although Win8 behavior is improved against
Win7 there is a problem specific to biometry.
The requests to our driver are sent by WinBio service. It does it on behalf
of apps and when we’re under control, we can close handles when necessary.
However, one of client is Windows logon. I just verified that there is
always pending request when logon screen is active. Which also means locked
screen. The request remains pending even when I press the power button and
screen, keyboard and mouse are turned off. It isn’t a desired behavior, IMO.
I understand your argument we should track requests and handles instead of
machine state but WinBio is open API and we may not have control over
application. If Windows logon breaks it, what we can expect from 3rd party
app writers? Isn’t it better if driver tracks machine state, cancels active
requests and powers the device off?
For Win32 apps, one can only hope they close their handles when they get
suspend notifications.
Do you mean Win32 apps are notified when system is going to connected
standby state? We will need it for our apps. The next problem with biometry
is it isn’t supported by WinRT (if something didn’t change).
Michal
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-506889-
xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Friday, June 29, 2012 4:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Runtime power management in Windows 8For Metro apps, we should (I say without actually looking up this specific
example) make sure that all handles are closed to sensor devices like
these
before the machine goes into connected standby. Your driver should be
tracking handles and requests, not whole machine state.For Win32 apps, one can only hope they close their handles when they get
suspend notifications. We expect that having Win32 apps open will reduce
your battery life. This is one reason that we’re only supporting Metro
apps
on ARM machines.(I’ll go look up the specifics on biometrics.)
Jake Oshins
Windows Kernel TeamThis message offers no warranties and confers no rights.
“Vodicka, Michal” wrote in message news:xxxxx@ntdev…
Thank you for detailed description. In the meantime I found
AssignS0IdleSettings() and was wondering if it is what I’m expected to
use.
Will try. It is new for me because for USB devices I used selective
suspend
and IWDFUsbTargetDevice UMDF methods to control it.My specific device is Biometric class SPB device. It is used by WinBio
service which keeps capture request there for a long time (it means “wait
until somebody touches sensor and then scan finger”). It probably means I
should use explicit StopIdle/ResumeIdle calls instead of power managed
queues. I can enable idle when the device is configured to wait for a
finger
but it shouldn’t be completely turned off. OTOH when there is no request,
it
can be turned off.> To answer your specific question about whether a driver can know when
the
> screen got turned off, the answer is yet, but that’s rarely the right
> question to be asking.Well, the motivation is following. User can run an application which
switches our device to a mode when it consumes relatively a lot of power.
Then user presses power button and expects that OS remains in S0 but all
unnecessary devices are turned off. Our device is unnecessary now but
continues to consume power because was instructed before to do it (there
is
an active request). If the driver is notified, it can cancel the request
and
lower the power consumption. But it needs to know about it (and shouldn’t
rely on app).Michal
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-506883-
> xxxxx@lists.osr.com] On Behalf Of Jake Oshins
> Sent: Friday, June 29, 2012 1:53 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Runtime power management in Windows 8
>
> You’re looking at it in a way that I would have recommended against even
> before Windows 8. You seem to think “system is leaving S0” meant “turn
> off
> my device.” I do admit that most people viewed it that way, and
> furthermore
> that before WDF, that was the only reasonable view to take.
>
> But since the introduction of WDF, we’ve tried to enable you to think
> about
> the problem differently. Leave your device turned off except when it
> needs
> to be turned on, even when the system is in S0. Using KMDF as an
example,
> call WdfDeviceAssignS0IdleSettings and then configure one or more power
> managed queues. Your device will remain turned on when there is actual
> work
> to do. If the reasons that it needs to be turned on can’t be
> represented
> with WDFREQUESTs, then use WdfDeviceStopIdle and
> WdfDeviceResumeIdle.
>
> When you’re targeting very aggressive runtime power management in
> machines
> that support an always-on, always-connected model, use
> WdfDeviceAssignS0IdleSettings with a “system managed idle timeout.”
> It’s
> one of the parameters to the KMDF 1.11 version of the parameter struct.
>
> Furthermore, you can integrate with the new runtime power framework,
> PoFx,
> by calling WdfDeviceWdmAssignPowerFrameworkSettings. This will enable
> an
> even lighter-weight power management model, one which is also available
> through WDM, though I won’t cover that here. The basic idea is that you
> mark your device as necessary or not necessary by calling
> WdfDeviceStopIdle
> and WdfResumeIdle. If your device has multiple independently
manageable
> components, you can add or remove references from them by calling
> through to
> the underlying WDM layer, using PoFxActivateComponent and
> PoFxIdleComponent.
> These are lightweight calls that indicate how many reasons there are to
> keep
> your components turned on.
>
> PoFx, sometimes in conjunction with a “Power Engine Plugin” which is a
> module supplied by the System-on-Chip vendor (Intel, AMD, Nvidia,
> Qualcomm,
> TI, etc.), will listen to your requests to keep components powered on.
> When
> a functional group of things has no reasons to be turned on, PoFx will
> direct them to move to specific idle states, F0 through Fx. When all
> components within a device may be moved out of F0, then the entire
device
> may also be moved out of F0. This is indicated by a callback from PoFx
> to
> your driver, which if you’re smart will be KMDF, handling this part for
> you.
> (See the use of WdfDeviceWdmAssignPowerFrameworkSettings above.)
>
> Many, many devices have no real states between “on” and “off.” For
these
> devices, it makes sense to report one component with one F-state, F0.
> When
> it’s idle, PoFx will tell the entire device that it can leave D0. The
> target D-state depends entirely on whether you need active wake signals.
>
> So imagine that you’re writing the driver for a sensor. It needs to be
> turned on when you’re taking measurements. It probably also needs to be
> turned on in a calibration phase. For these things, if possible, I
> would
> just use a power managed queue and let the device be turned off when
> you’re
> not using it.
>
> The exact conditions for when a device must be turned on vary greatly
from
> device class to device class. If you want to ask about specific
> classes,
> I’ll try to help.
>
> To answer your specific question about whether a driver can know when
the
> screen got turned off, the answer is yet, but that’s rarely the right
> question to be asking.
>
> Jake Oshins
> Windows Kernel Team
>
> This message offers no warranties and confers no rights.
>
> -----------------------------------------------------------
>
> “Vodicka, Michal” wrote in message news:xxxxx@ntdev…
>
> > You get a very interesting set of relationships, especially regarding
> > power.
>
> Yes, this is what I mean. Interesting and it is unclear who is
> responsible
> for what. Currently I have SPI device but it is the same for I2C, data
> lines
> are separate from power ones.
>
> As a side note I like SPB architecture. One driver can be used for both
> I2C
> and SPI devices with almost no additional work.
>
> > THEN you need to factor-in WAKE, which is what you’re (mostly) asking
> > about here.
>
> Actually, wake is only part of the question. First I’d need to know how
> should my driver decide when to power off the device. When user of
> phone/tablet presses power button, the system should remain in S0 and
> minimize power consumption. Turn off display and all unnecessary
> devices.
> One of my questions is how is the driver notified about this event?
> Well,
> I’m just preparing experiment which could reveal it but I have a feeling
> it
> isn’t the right way how to get such an info
>
> Michal
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-506849-
> > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> > Sent: Thursday, June 28, 2012 8:32 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE:[ntdev] Runtime power management in Windows 8
> >
> > [quote]
> > It differs from other stacks because there is SPB controller driver
> > and
> > function device driver opens it as remote target
> > [/quote]
> >
> > This is tied to what I think is one of the most interesting and
> > significant
> > architectural changes in Win8 in my mind.
> >
> > Prior to Win8, we always had devices in a branch of the device tree
> > that
> > terminated in a single place. A device got its data, its power, and
> > its
> > interrupts from a single place. The model, really, was PCI. Your bus
> > driver is
> > responsible for giving you your interrupts, provides the hardware
> > resources
> > from which you receive your data, and can manipulate the power on the
> slot
> > into which your device is plugged. All relatively simple.
> >
> > Sure, we’ve attempted to deal with cross-branch power dependencies
and
> > such things, but never truly successfully.
> >
> > Enter Win8. NOW, your device can get its data from the I2C bus, gets
> > its
> > interrupts from one ore more GPIO lines, and the power? Well, the
power
> > for your device is probably controlled by somebody entirely different.
> > And
> > possibly, but not necessarily, the power for the I2C (where you get
> > your
> > data) and the power for the GPIO (where you get your interrupt) is
> > supplied
> > by somebody else yet.
> >
> > You get a very interesting set of relationships, especially regarding
> > power.
> >
> > When you combine this with the fact that your device can have multiple
> > “functional” power states within D0, and very rapidly transition into
> > and
> > outof these functional power states, you get some very interesting
power
> > management capabilities and issues.
> >
> > THEN you need to factor-in WAKE, which is what you’re (mostly) asking
> > about
> > here.
> >
> > Whew!
> >
> > Peter
> > OSR
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
> NOTE: The information in this message is intended for the personal and
> confidential use of the designated recipient(s) named above. To the
> extent
> the recipient(s) is/are bound by a non-disclosure agreement, or other
> agreement that contains an obligation of confidentiality, with
> AuthenTec,
> then this message and/or any attachments shall be considered
> confidential
> information and subject to the confidentiality terms of that agreement.
> If
> the reader of this message is not the intended recipient named above,
> you
> are notified that you have received this document in error, and any
> review,
> dissemination, distribution or copying of this message is strictly
> prohibited. If you have received this document in error, please delete
> the
> original message and notify the sender immediately.
> Thank You!
> AuthenTec, Inc. http://www.authentec.com/
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServerNOTE: The information in this message is intended for the personal and
confidential use of the designated recipient(s) named above. To the extent
the recipient(s) is/are bound by a non-disclosure agreement, or other
agreement that contains an obligation of confidentiality, with AuthenTec,
then this message and/or any attachments shall be considered confidential
information and subject to the confidentiality terms of that agreement.
If
the reader of this message is not the intended recipient named above, you
are notified that you have received this document in error, and any
review,
dissemination, distribution or copying of this message is strictly
prohibited. If you have received this document in error, please delete the
original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NOTE: The information in this message is intended for the personal and
confidential use of the designated recipient(s) named above. To the extent
the recipient(s) is/are bound by a non-disclosure agreement, or other
agreement that contains an obligation of confidentiality, with AuthenTec,
then this message and/or any attachments shall be considered confidential
information and subject to the confidentiality terms of that agreement. If
the reader of this message is not the intended recipient named above, you
are notified that you have received this document in error, and any review,
dissemination, distribution or copying of this message is strictly
prohibited. If you have received this document in error, please delete the
original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/