> From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, September 16, 2003 7:10 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] RE: Question on power management (was Re: BulkUsb
sample experiences?)The system iterates over all possible standby states, starting with the
deepest state. Anytime a driver vetos a query to into an S state, a
lighter (if supported) S state is attempted until you run out of S
states.
What exactly means “if supported”? As I wrote previously, XP at notebook I
use for test asks for S3 and when vetoed OS gives up. On the second computer
(a desktop) OS asks for S1 at first. How OS determines which power state is
supported and what S1, S2 and S3 really mean (i.e. differences)?
BTW, could somebody explain how OS determines which processor states (C1 –
C3) are supported and when they’re selected?
Now, for mice
… on XP and later, the mouse is automatically armed
for wake if the mouse can wake the machine from the machine’s deepest
sleep state. If the mouse cannot wake the machine from the deepest
state, it is still possible to arm the mouse, but mouclass will reject
any S states that the machine attempts to go into from which it cannot
wake the machine. Since the user is explicitly enabling this feature
(although perhaps unaware of the consequences), this was termed an
acceptable tradeoff.
Interesting. If I understand it correctly, mouclass rejects S states from
which can’t wake the machine and hopes OS will ask for next S state from
which it is possible. When it doesn’t, mouclass prevents standby. Right? It
seems original bulkusb example uses similar logic. However, it is acceptable
only if user can control this feature.
I’d prefer more automatic solution. Is it possible to determine all S states
for which OS will ask when deeper are vetoed? It would allow to reject power
states from which wakeup isn’t possible only if driver knows OS will
eventually ask for a state from which it is possible. If there is no such a
state, driver would accept the deepest allowing standby mode. A notebook I
use supports wakeup only from S0 so it is clear vetoing S3 has no sense and
only makes trouble for user.
As you wrote, user can be unaware of the consequences. I guess ordinal user
never opens device manager and has no chance to see a) why a device isn’t
able to wake machine or b) why device prevents standby. It means the best
default value depends on hardware configuration. That’s why I believe driver
should make automatic decision instead because has more information about
current configuration. The question is how to make this decision.
DEVICE_CAPABILITIES can give a hint but not always because driver doesn’t
know for which S state would OS ask.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, September 16, 2003 8:16 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question on power management (was Re: BulkUsb sample
experiences?)Then a question to anybody who knows:
“Standby” can be mapped to S1, S2 or S3. How it is determined to what
ACPI
power state “Standby” is mapped?
I’d like to know it, too.
Note that, for notebooks, “Standby” is obviously mapped to different
states
depending on whether the USB mouse is attached and whether wait/wake is
enabled
from it.
Not only for notebooks…
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]