Hai,
I am writing a USB Minidriver for my video capture device. I don’t
want to allow my device to go for suspend state during capture, for
that I returned error code to the SRB_CHANGE_POWER_STATE, but still
the OS goes to suspend state irrespective of the error code what I
returned. How should I handle this situation.
Thanks in advance
Kannan
Get your free Australian email account at http://www.start.com.au
Hi,
You will get a PNP Irp with Minor function “Query Device Capabilities” in
that you can specify the Capabilities of your device. Filling it with
appropriate information in the POWER info of the structure may solve your
problem. You can give it a try.
regards,
shivas
-----Original Message-----
From: kannan Thankavel [SMTP:xxxxx@start.com.au]
Sent: Tuesday, March 19, 2002 10:02 AM
To: NT Developers Interest List
Subject: [ntdev] Preventing the system to go in to suspend stateHai,
I am writing a USB Minidriver for my video capture device. I don’t
want to allow my device to go for suspend state during capture, for
that I returned error code to the SRB_CHANGE_POWER_STATE, but still
the OS goes to suspend state irrespective of the error code what I
returned. How should I handle this situation.Thanks in advance
Kannan
Get your free Australian email account at http://www.start.com.au
You are currently subscribed to ntdev as: xxxxx@bla.satyam.com
To unsubscribe send a blank email to %%email.unsub%%
**************************************************************************
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************
You need to go about the problem a little differently. If the system
starts suspending, you need to make that happen gracefully. This is
important, since if a user presses the power button, she will get
frustrated if it doesn’t work.
If you want to keep the machine from timing out and suspending (i.e.
suspending for reasons not initiated by the user,) you need to use the
SetThreadExecutionState API. (Or its kernel-mode equivalent
ZwSetThreadExecutionState.) Use the ES_SYSTEM_REQUIRED flag as a
parameter. The machine will not go to sleep (without user intervention)
until after you clear this flag or your thread exits.
Jake Oshins
Windows Core OS Team
-----Original Message-----
Subject: Preventing the system to go in to suspend state
From: kannan Thankavel
Date: Tue, 19 Mar 2002 4:31:51 +0000
X-Message-Number: 36
Hai,
I am writing a USB Minidriver for my video capture device. I don’t
want to allow my device to go for suspend state during capture, for
that I returned error code to the SRB_CHANGE_POWER_STATE, but still
the OS goes to suspend state irrespective of the error code what I
returned. How should I handle this situation.
Thanks in advance
Kannan
What?? So, a driver cannot reject a suspend if it is in the middle of
something in general? Is that what is being said?
If an application is busy getting data from a driver, is it not proper to
let the user know that they need to shut down the app before trying to send
the system to sleep mode?
–
Bill McKenzie
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
You need to go about the problem a little differently. If the system
starts suspending, you need to make that happen gracefully. This is
important, since if a user presses the power button, she will get
frustrated if it doesn’t work.
If you want to keep the machine from timing out and suspending (i.e.
suspending for reasons not initiated by the user,) you need to use the
SetThreadExecutionState API. (Or its kernel-mode equivalent
ZwSetThreadExecutionState.) Use the ES_SYSTEM_REQUIRED flag as a
parameter. The machine will not go to sleep (without user intervention)
until after you clear this flag or your thread exits.
Jake Oshins
Windows Core OS Team
-----Original Message-----
Subject: Preventing the system to go in to suspend state
From: kannan Thankavel
Date: Tue, 19 Mar 2002 4:31:51 +0000
X-Message-Number: 36
Hai,
I am writing a USB Minidriver for my video capture device. I don’t
want to allow my device to go for suspend state during capture, for
that I returned error code to the SRB_CHANGE_POWER_STATE, but still
the OS goes to suspend state irrespective of the error code what I
returned. How should I handle this situation.
Thanks in advance
Kannan
I’m sorry. I gave you bad information. There is no Zw entry-point for
this API. It’s only available from user-mode. I’ll take this as a
suggestion to change this in some possible future version.
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
Subject: RE: Preventing the system to go in to suspend state
From: “Jake Oshins”
Date: Tue, 19 Mar 2002 01:15:56 -0800
X-Message-Number: 4
You need to go about the problem a little differently. If the system
starts suspending, you need to make that happen gracefully. This is
important, since if a user presses the power button, she will get
frustrated if it doesn’t work.
If you want to keep the machine from timing out and suspending (i.e.
suspending for reasons not initiated by the user,) you need to use the
SetThreadExecutionState API. (Or its kernel-mode equivalent
ZwSetThreadExecutionState.) Use the ES_SYSTEM_REQUIRED flag as a
parameter. The machine will not go to sleep (without user intervention)
until after you clear this flag or your thread exits.
Jake Oshins
Windows Core OS Team
-----Original Message-----
Subject: Preventing the system to go in to suspend state
From: kannan Thankavel
Date: Tue, 19 Mar 2002 4:31:51 +0000
X-Message-Number: 36
Hai,
I am writing a USB Minidriver for my video capture device. I don’t
want to allow my device to go for suspend state during capture, for
that I returned error code to the SRB_CHANGE_POWER_STATE, but still
the OS goes to suspend state irrespective of the error code what I
returned. How should I handle this situation.
Thanks in advance
Kannan
To be precise, a driver is welcome to fail IRP_MN_QUERY_POWER. It may
not fail IRP_MN_SET_POWER. This means that you can reject a
non-critical suspend if there is something absolutely uninterruptable
going on. This will cause a pop-up that tells the user that your driver
failed.
But that user experience could be vastly improved. In most situations,
if you pend your other IRPs after you get IRP_MN_QUERY_POWER, then
you’ll be able to suspend without much delay once you get
IRP_MN_SET_POWER.
In most of the cases where you’re doing something that really shouldn’t
be interrupted, like burning a CD, or streaming to tape, then you’ll
also have some user-mode interface associated with what you’re doing.
And that’s a better place to intercept the power messages and deal with
them. That way you can interact with the user, explaining the situation
and dealing with it appropriately, before it ever gets to the driver.
Furthermore, direct user-initiated actions, like pushing the power
button or closing the lid of a laptop, should be respected. I’m sure
you know how frustrating it is to be told by the flight attendant that
you must turn your laptop off immediately, due to FAA regulations,
especially when the laptop isn’t respecting your wishes.
In the case you mention, both the app and the driver will still be there
on a resume. It is often sufficient to just pend the IRPs sent down by
the app. Then handle them when the machine wakes up again. The app
will continue running. If the suspend affected the app’s connection to
something external, then the app would have to deal with that. It’s not
much different than a network failure or a device being
surprise-removed. Again, this should be handled at the app level before
the drivers get involved.
As a final note, rejecting a suspend when it has been initiated by
closing the lid of a laptop is the worst-possible user scenario. First
of all, the user can’t see the screen any more. So any pop-up about a
failed driver, or even polite UI from an app, is meaningless.
Furthermore, one of the most common things that people do after closing
the lid of the machine is to stuff it into a briefcase or other bag,
which is often quite insulative. This will cause the machine to
continue to drain its battery and it will usually cause quite a bit of
heat. In most cases, the heat is handled well. But I’ve even seen one
machine that melted its case when this happened.
This is why I said that failing the suspend IRP was the wrong approach.
I strongly believe that by the time the power IRPs are being sent, the
only reasonable behavior is to handle them successfully. There are lots
of real-world scenarios where a machine shouldn’t time-out and go to
sleep. But that can be handled with SetThreadExecutionState. When the
user actively tells the machine to sleep, hibernate or shut down, you
should respect that.
Jake Oshins
Windows Kernel Group
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
Subject: Re: Preventing the system to go in to suspend state
From: “Bill McKenzie”
Date: Tue, 19 Mar 2002 11:15:10 -0600
X-Message-Number: 26
What?? So, a driver cannot reject a suspend if it is in the middle of
something in general? Is that what is being said?
If an application is busy getting data from a driver, is it not proper
to
let the user know that they need to shut down the app before trying to
send
the system to sleep mode?
–
Bill McKenzie
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
You need to go about the problem a little differently. If the system
starts suspending, you need to make that happen gracefully. This is
important, since if a user presses the power button, she will get
frustrated if it doesn’t work.
If you want to keep the machine from timing out and suspending (i.e.
suspending for reasons not initiated by the user,) you need to use the
SetThreadExecutionState API. (Or its kernel-mode equivalent
ZwSetThreadExecutionState.) Use the ES_SYSTEM_REQUIRED flag as a
parameter. The machine will not go to sleep (without user intervention)
until after you clear this flag or your thread exits.
Jake Oshins
Windows Core OS Team
-----Original Message-----
Subject: Preventing the system to go in to suspend state
From: kannan Thankavel
Date: Tue, 19 Mar 2002 4:31:51 +0000
X-Message-Number: 36
Hai,
I am writing a USB Minidriver for my video capture device. I don’t
want to allow my device to go for suspend state during capture, for
that I returned error code to the SRB_CHANGE_POWER_STATE, but still
the OS goes to suspend state irrespective of the error code what I
returned. How should I handle this situation.
Thanks in advance
Kannan
Jake,
thanks very much for giving us some background info. I wish there were
lots of similar comments in the ddk docs. But that is what is missing
between the raw API descriptions. You often do not know the purpose
behind all that what is going on. You and your collegues should write
a book named 'The DDK the way we meant it' with all the 'What is that
for?' stories. As long as this book needs to be finished I stick
around the newsgroups/lists to get my share 
| Norbert Kawulski | mailto:xxxxx@stollmann.de |
| Stollmann E+V GmbH, Development | http://www.stollmann.de |
--If it's ISDN or Bluetooth, make sure it's driven by Stollmann--
"Credit is the device that allows us to start at the bottom and dig
ourselves a hole."
To be precise, a driver is welcome to fail IRP_MN_QUERY_POWER. It may
----------------.... cut --------------
I second the thank you Jake!
And I agree, we try to get the meaning from the DDK, whitepapers and such,
but I would love to have a day and sit down and talk out some Power/PnP
questions with you folks!
–
Bill McKenzie
“Norbert Kawulski” wrote in message news:xxxxx@ntdev…
>
>
> Jake,
> thanks very much for giving us some background info. I wish there were
> lots of similar comments in the ddk docs. But that is what is missing
> between the raw API descriptions. You often do not know the purpose
> behind all that what is going on. You and your collegues should write
> a book named ‘The DDK the way we meant it’ with all the ‘What is that
> for?’ stories. As long as this book needs to be finished I stick
> around the newsgroups/lists to get my share 
>
> Regards,
> -----------------------------------------------------------------
> | Norbert Kawulski | mailto:xxxxx@stollmann.de |
> | Stollmann E+V GmbH, Development | http://www.stollmann.de |
> --If it’s ISDN or Bluetooth, make sure it’s driven by Stollmann–
>
> “Credit is the device that allows us to start at the bottom and dig
> ourselves a hole.”
>
>
> > To be precise, a driver is welcome to fail IRP_MN_QUERY_POWER. It may
> ----------------… cut --------------
>
>
>
Once again, I spoke too soon. I forgot about PoSetSystemState. This
API will do what you want, and it’s in ntddk.h. It’s a little different
from SetThreadExecutionState, since the effect of it lasts beyond the
life of the calling thread. So you have to call it again when your
driver is finished.
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Jake Oshins
Sent: Friday, March 22, 2002 12:17 AM
To: ‘NT Developers Interest List’
Subject: RE: Preventing the system to go in to suspend state
I’m sorry. I gave you bad information. There is no Zw entry-point for
this API. It’s only available from user-mode. I’ll take this as a
suggestion to change this in some possible future version.
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
Subject: RE: Preventing the system to go in to suspend state
From: “Jake Oshins”
Date: Tue, 19 Mar 2002 01:15:56 -0800
X-Message-Number: 4
You need to go about the problem a little differently. If the system
starts suspending, you need to make that happen gracefully. This is
important, since if a user presses the power button, she will get
frustrated if it doesn’t work.
If you want to keep the machine from timing out and suspending (i.e.
suspending for reasons not initiated by the user,) you need to use the
SetThreadExecutionState API. (Or its kernel-mode equivalent
ZwSetThreadExecutionState.) Use the ES_SYSTEM_REQUIRED flag as a
parameter. The machine will not go to sleep (without user intervention)
until after you clear this flag or your thread exits.
Jake Oshins
Windows Core OS Team
-----Original Message-----
Subject: Preventing the system to go in to suspend state
From: kannan Thankavel
Date: Tue, 19 Mar 2002 4:31:51 +0000
X-Message-Number: 36
Hai,
I am writing a USB Minidriver for my video capture device. I don’t
want to allow my device to go for suspend state during capture, for
that I returned error code to the SRB_CHANGE_POWER_STATE, but still
the OS goes to suspend state irrespective of the error code what I
returned. How should I handle this situation.
Thanks in advance
Kannan
Speaking of being frustrated at not being able to hit the power button
or closing the lid of the laptop; can you inform the Microsoft Office
team, that Microsoft Outlook 2002 blocks the shutdown process by
bringing up a dialog box saying do not shutdown the system until you
close Outlook?
Thanks,
Rob
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Friday, March 22, 2002 11:18 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Preventing the system to go in to suspend state
Once again, I spoke too soon. I forgot about PoSetSystemState. This
API will do what you want, and it’s in ntddk.h. It’s a little different
from SetThreadExecutionState, since the effect of it lasts beyond the
life of the calling thread. So you have to call it again when your
driver is finished.
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Jake Oshins
Sent: Friday, March 22, 2002 12:17 AM
To: ‘NT Developers Interest List’
Subject: RE: Preventing the system to go in to suspend state
I’m sorry. I gave you bad information. There is no Zw entry-point for
this API. It’s only available from user-mode. I’ll take this as a
suggestion to change this in some possible future version.
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
Subject: RE: Preventing the system to go in to suspend state
From: “Jake Oshins”
Date: Tue, 19 Mar 2002 01:15:56 -0800
X-Message-Number: 4
You need to go about the problem a little differently. If the system
starts suspending, you need to make that happen gracefully. This is
important, since if a user presses the power button, she will get
frustrated if it doesn’t work.
If you want to keep the machine from timing out and suspending (i.e.
suspending for reasons not initiated by the user,) you need to use the
SetThreadExecutionState API. (Or its kernel-mode equivalent
ZwSetThreadExecutionState.) Use the ES_SYSTEM_REQUIRED flag as a
parameter. The machine will not go to sleep (without user intervention)
until after you clear this flag or your thread exits.
Jake Oshins
Windows Core OS Team
-----Original Message-----
Subject: Preventing the system to go in to suspend state
From: kannan Thankavel
Date: Tue, 19 Mar 2002 4:31:51 +0000
X-Message-Number: 36
Hai,
I am writing a USB Minidriver for my video capture device. I don’t
want to allow my device to go for suspend state during capture, for
that I returned error code to the SRB_CHANGE_POWER_STATE, but still
the OS goes to suspend state irrespective of the error code what I
returned. How should I handle this situation.
Thanks in advance
Kannan
—
You are currently subscribed to ntdev as: xxxxx@cdp.com
To unsubscribe send a blank email to %%email.unsub%%