RE: Question on power management (was Re: BulkUsb sam ple experiences?)

If supported means the combination of what the bios reports plus known
motherboard/hardware limitations and bugs.

I can't answer the question on processor states, sorry.

A driver can't determine which other S state the machine can
successfully go into, there could be another driver that rejects that
state. At this point, we keep it simple. This is why the automatic arm
for wake only occurs if the mouse can wake the machine from its deepest
sleep state. In this state, we do not ever reject a request to go into
standby b/c the mouse (and keyboard as well actually) support them all
for wake.

D

This posting is provided "AS IS" with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, September 16, 2003 11:13 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: Question on power management (was Re: BulkUsb sam
ple experiences?)

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 :slight_smile: ... 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]


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> > 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)?

Read the ACPI spec.

BTW, could somebody explain how OS determines which processor states
(C1 –
C3) are supported and when they’re selected?

Read the ACPI spec.

Loren