Mouclass doesn’t need to support selective suspend. Support for SS
happens at a lower layer at the port driver (it is the one that knows if
it is idle or not). For HID devices, HIDCLASS does this on behalf of
its PDOs at its FDO level. I8042prt doesn’t have any concept of being
idle.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, June 08, 2004 6:50 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] GUID_POWER_DEVICE_WAKE_ENABLE
Thanks, I wanted to be sure. My driver already supports
GUID_POWER_DEVICE_ENABLE, I guess it is almost mandatory when selective
suspend is used.
It would be nice if both docs and examples are updated this way. I
wonder why mouclass doesn’t support selective suspend, yet. BulkUsb and
SelSups samples should use these GUIDs to show how it should be exactly
done.
As for WDF, I’m affraid I wouldn’t be allowed to rewrite whole driver
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http:://www.upek.com]
From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, June 09, 2004 3:23 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] GUID_POWER_DEVICE_WAKE_ENABLE
You got the gist of it. The WW is overloaded for wake while the
machine
is running and sleeping, but the driver must make the contextual
distinction between the two.
GUID_POWER_DEVICE_WAKE_ENABLE controls the device being armed for wake
when the machine goes to sleep. Basically, send your WW while the
machine is in S0 if you are trying to USB SS. When the Sx power irp
comes, you can check to see if a WW is already pending and if so and
wake is enabled, keep it pended (assuming you do not have to
initialize
the Device to wake for certains events which means you must reenter
D0).
If one is pended and wake is not enabled, you must cancel the ww
request.
In fact, there is another GUID, GUID_POWER_DEVICE_ENABLE, which
represents the device idling out while the machine is running.
Providing this WMI GUID enables another checkbox on the same power
managed page which controls this setting. This means the user can
control if your device even attempts USB SS. This of course adds a
new
wrinkle to the power state machine and more cases need to be handled.
BTW, WDF handles all of this for you :). It implements what I
mentioned
above except that it always cancels the WW irp representing the wake
while the machine is in S0 irp (if enabled) when the machines goes
into
Sx. If the device is enabled for both idle in S0 and wake from Sx, a
WW
request will be resent down the stack. It is actually much simpler to
do this way then to have logic which attempts to only selectively
cancel
the S0 WW irp when going into Sx.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, June 08, 2004 6:01 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] GUID_POWER_DEVICE_WAKE_ENABLE
WMI class GUID in subject enables “Allow this device to bring the
computer out of standby” checkbox in the Power Management tab on the
device property sheet. According to DDK docs it should control if
device
sends wait wake IRP (IRP_MN_WAIT_WAKE) or not. DDK samples (mouclass,
kbdclass) enable this GUID and in turn Power Management tab when
system
can be awaken by this device:
#define WAITWAKE_SUPPORTED(port) ((port)->MinDeviceWakeState >
PowerDeviceD0 && \
(port)->MinSystemWakeState >
PowerSystemWorking)
Everything makes sense until selective suspend comes into play. There
wait wake IRP has two roles; it is used for system wakeup as before
and
also when device is suspended whereas system is in S0 state and device
awakens because of external action (mouse move) and needs to inform
driver about it. The question is when the GUID should be enabled and
what it should control. Unfortunately, no DDK sample which uses it
supports selective suspend, too.
If DDK docs is strictly followed and wait wake IRP isn’t sent when
check
box is unchecked, device couldn’t awake driver from selective suspend.
I>
guess it is incorrect and wait wake IRP should be sent anyway and
cancelled only when system is going to low power state. The checkbox
should control only system wakeup as its name indicate. If device
can’t
wakeup system from low power state, there is nothing to control and
checkbox should be disabled (GUID not supported).
However, it is only my interpretation and I don’t know how it was
really
mentioned. This part of DDK docs seem outdated. Currently my driver
has
enabled checkbox when device supports remote wakeup (if it is
indicated
in USB configuration descriptor) and sends wait wake IRP if checkbox
is
checked or selective suspend is enabled (i.e. IRP isn’t sent only when
both checkboxes are unchecked). Currently one customer claims checkbox
should be disabled (unavailable) when their computer can’t be awaken
from suspend state (MinSystemWakeState is S0) and the request makes
some
sense. Before making change I’d like to hear others opinion.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http:://www.upek.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
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@upek.com
To unsubscribe send a blank email to xxxxx@lists.osr.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
). Also, since