Dear all,
Because Windows XP in box driver usbvideo.sys don’t support usb selective suspend,so I want to use usbvideo.sys lower filter to implement this function.
I will send the idle pending IRP to bus driver if i havn’t received any IRP in 5 seconds.
Do you think this filter driver will work well? Does it will affect usbvideo.sys driver’s working?
thank you very much.
Denny
You will be lucky if this works. The Dx (and potentially) wait wake irps will go through usbvideo. Usbvideo is the power policy owner and the only one in the stack who can request any kind of state changing power irp
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@gmail.com
Sent: Sunday, June 14, 2009 5:55 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] use filter driver to implement USB selective suspend function
Dear all,
Because Windows XP in box driver usbvideo.sys don’t support usb selective suspend,so I want to use usbvideo.sys lower filter to implement this function.
I will send the idle pending IRP to bus driver if i havn’t received any IRP in 5 seconds.
Do you think this filter driver will work well? Does it will affect usbvideo.sys driver’s working?
thank you very much.
Denny
—
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
Dear Doron Holan,
When I found idle, I send a idle pending irp to the bus driver, then the bus driver will callback my filter driver, at that time I send a power IRP from D0 to D2. If there is any read/write IRP, then I cancel the pending idle IRP, and send power IRP from D2 to d0.
Do you think if there is other issue?
Curruntly, it seems to be work ok.
I will test more.
thank you very much.
Denny
My point is that usbvideo’s power dispatch routine may not handle a dx or ww that it did not request properly. This could lead to weird behaviors or an immediate bugcheck. The fact that it kinda works now is where you are getting lucky
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@gmail.com
Sent: Sunday, June 14, 2009 9:03 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] use filter driver to implement USB selective suspend function
Dear Doron Holan,
When I found idle, I send a idle pending irp to the bus driver, then the bus driver will callback my filter driver, at that time I send a power IRP from D0 to D2. If there is any read/write IRP, then I cancel the pending idle IRP, and send power IRP from D2 to d0.
Do you think if there is other issue?
Curruntly, it seems to be work ok.
I will test more.
thank you very much.
Denny
—
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
Doron Holan
thank you very much.
Denny
Wouldn’t an approach be to have an other driver below Usbvideo which
enumerates a new pdo where a new stack is created and on which the usbvideo
driver gets loaded. That lower driver could then send the relevant Idle and
power IRPs when there is no communication.
/Faik
On Mon, Jun 15, 2009 at 7:35 AM, wrote:
> Doron Holan
> thank you very much.
>
> Denny
>
> —
> 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
>
I can confirm that what Velio Roumenov suggests (a bus driver splitting the power stack into two independent components above and below) is the right approach for virtually any power management related “filtering” including a request by the OP. A filter driver proper will generally not work for that purpose.
Regards,
Ilya Faenson
Rockville, MD USA
A bus driver will work. You must install your driver as the fdo on the stack that usbvideo was running on initially. You can even do this with kmdf to take advantage of its usb sel suspend implementation, although the solution looks a little different. With the kmdf solution, you have a kmdf fdo which enables sel suspend and an upper filter which enumerated the pdo that usbvideo will load on and fwd the io down the parent stack.
You need to split the 2 apart in kmdf b/c if the pwr pol owner is the one that enums the pdo, it enforces the pnp rule that if a child has power, the parent also must have power which will always be the case b/c usbvideo will never turn itself odd, meaning kmdf will never suspend the parent. On the hand, if a non pwr pol owner (the filter) enums a pdo, there is no way to enforce the parent/child power rule so kmdf does not try. This let’s you have an always powered on child with an idled out/powered off parent.
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
From: Faik Riza
Sent: Monday, June 15, 2009 4:14 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] use filter driver to implement USB selective suspend function
Wouldn’t an approach be to have an other driver below Usbvideo which enumerates a new pdo where a new stack is created and on which the usbvideo driver gets loaded. That lower driver could then send the relevant Idle and power IRPs when there is no communication.
/Faik
On Mon, Jun 15, 2009 at 7:35 AM, > wrote:
Doron Holan
thank you very much.
Denny
—
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
— 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
Dear Velio Roumenov,Ilya Faenson and Doron Holan
thank you very much.
But Doron Holan, I cannot catch what you mean well. I repeat that.
I need to create a driver which function as function driver (power policy ower). This driver also will create a child pdo and this pdo will cause usbvideo.sys will be loaded. And child power policy (usbvideo.sys) will have way to be consistent with parent (our new function driver). Right?
thank you very much.
Denny
Not exactly, you have this right now
Usbvideo
|
|
USB PDO
What I am suggesting is this
USBVideo
|
|
PDO enumerated by the filter
|
|
Filter (a KMDF driver written by you)-----+
|
|
FDO (a KMDF driver written by you)
|
|
USB PDO
The FDO enables USB selective suspend via KMDF. The filter is the one that enumerates the PDO that usbvideo will load on. When the io hits the PDO enumerated by the filter, the filter just sends and forgets all io to the FDO
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, June 15, 2009 7:19 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] use filter driver to implement USB selective suspend function
Dear Velio Roumenov,Ilya Faenson and Doron Holan
thank you very much.
But Doron Holan, I cannot catch what you mean well. I repeat that.
I need to create a driver which function as function driver (power policy ower). This driver also will create a child pdo and this pdo will cause usbvideo.sys will be loaded. And child power policy (usbvideo.sys) will have way to be consistent with parent (our new function driver). Right?
thank you very much.
Denny
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
Hi Doron,
A follow up question on this. Will this also work for a composite device case where the filter driver enumerates multiple PDOs ?
Thanks,
Nate
In the composite device case, usbccgp will enumerate you usb pdo instead of usbhub. I would NOT recommend replacing usbccgp in the topology with your own driver if any of the usbccgp PDOs have msft clas drivers loading on them. You will have to now mimic all of usbccgp’s behavior, alot of which is undocumented. Instead, you do the same thing i suggested before on each of the usbccgp PDOs
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@coolgoose.com
Sent: Tuesday, June 16, 2009 1:13 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] use filter driver to implement USB selective suspend function
Hi Doron,
A follow up question on this. Will this also work for a composite device case where the filter driver enumerates multiple PDOs ?
Thanks,
Nate
—
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
Doron Holan wrote:
I would NOT recommend replacing usbccgp in the topology with
your own driver if any of the usbccgp PDOs have msft clas drivers
loading on them. You will have to now mimic all of usbccgp’s
behavior, alot of which is undocumented.
Are you saying/implying that usbccgp invokes “special” behaviour for child PDOs on which MSFT class drivers are sitting? I mean, beyond the usual “complications” in writing one’s own generic parent?
For example, reading an OS descriptor from the USB PDO, and then slapping a compatible ID on the appropriate child PDO, that sort of thing?
There is no internal comm between the class driver and the usbccgp pdo, rather it is a testing issue b/c the io interface is not exactly clear. The real bugger you do not want to touch is that usbccgp must impl sel suspend for itself in coordination with each PDO’s sel suspend state. That is an endless source of complexity you do not want
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, June 16, 2009 7:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] use filter driver to implement USB selective suspend function
Doron Holan wrote:
> I would NOT recommend replacing usbccgp in the topology with
> your own driver if any of the usbccgp PDOs have msft clas drivers
> loading on them. You will have to now mimic all of usbccgp’s
> behavior, alot of which is undocumented.
Are you saying/implying that usbccgp invokes “special” behaviour for child PDOs on which MSFT class drivers are sitting? I mean, beyond the usual “complications” in writing one’s own generic parent?
For example, reading an OS descriptor from the USB PDO, and then slapping a compatible ID on the appropriate child PDO, that sort of thing?
—
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
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, June 16, 2009 5:28 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] use filter driver to implement USB
selective suspend functionThe real bugger you do not
want to touch is that usbccgp must impl sel suspend for
itself in coordination with each PDO’s sel suspend state.
That is an endless source of complexity you do not want
From which OS version it really works? Recently I experimented with a
composite device and at XP selective suspend with usbccgp just locks up.
It is possible to suspend device but not awake it back. Power IRP is
never completed. It seems at Vista and Win7 it works.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Dear Doron Holan , Chris Aseltine and everyone
thank you very much.
Doron Holan, I also want to ask you why do we need a filter driver to enumate a PDO in your framework? Can function driver do this job?
As far as usbccgp is concerned, I think usbccgp will create a composite PDO and video interface PDO, and our function driver (in your framwork) only is loaded on the later. so I think we needn’t to care composite PDO. right?
thank you very much.
denny
you do not need to care about the composite case. read my previous response about the power rules. to repeat: pnp rules say that when a child is powered on, the parent must be powered on. KMDF enforces this. If the FDO (the power policy owner (PPO)) enuemrates the PDO, the PDO will never power down (i.e. idle) so the FDO will never idle so there will be no selective suspend. what you need is to break this requirement and have a PDO that can be powered on, but the parent who is idled and powered off. KMDF allows this type of power relationship between PDO and parent device when the parent device is NOT the PPO in the stack. A filter is not the PPO by default. So by enumerating the PDO from the filter instead of the FDO, you allow the child to stay on while the FDO (who is the PPO) can idle out (and in reality the FDO has no idea the filter enumerated a PDO at all).
d
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of xxxxx@gmail.com [xxxxx@gmail.com]
Sent: Wednesday, June 17, 2009 8:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] use filter driver to implement USB selective suspend function
Dear Doron Holan , Chris Aseltine and everyone
thank you very much.
Doron Holan, I also want to ask you why do we need a filter driver to enumate a PDO in your framework? Can function driver do this job?
As far as usbccgp is concerned, I think usbccgp will create a composite PDO and video interface PDO, and our function driver (in your framwork) only is loaded on the later. so I think we needn’t to care composite PDO. right?
thank you very much.
denny
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
Doron Holan
I learn much from you.
thank you very much.
Denny
Doron and others,
I have one more question on following
old function driver (KMDF w/ continous reader started)
|
|
PDO enumerated by the filter
|
|
Filter (a KMDF driver written by you)-----+
|
|
FDO (a KMDF driver written by you)
|
|
USB PDO
If the “old function driver” is based of KMDF and has started continous readers then can the “FDO” still timeout and go into idle? Can the “FDO” use power-managed queue and forward the request with send and forget?
Or are there any guidelines to implement the “FDO” and “Filter” in such a way that it will work for any function driver that loads on the PDO and provide a clean break in power relationship?
Thanks again,
Nate
You cannot create a generic driver which does this b/c each usb interface is different and you don’t have enough context to know which io requires power and which can pend and still allow idle. You would not fwd the io through the FDO via a power managed queue if you want it to idle, basically, each read sent down in this model would reset the idle timer
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@coolgoose.com
Sent: Tuesday, June 23, 2009 9:29 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] use filter driver to implement USB selective suspend function
Doron and others,
I have one more question on following
old function driver (KMDF w/ continous reader started)
|
|
PDO enumerated by the filter
|
|
Filter (a KMDF driver written by you)-----+
|
|
FDO (a KMDF driver written by you)
|
|
USB PDO
If the “old function driver” is based of KMDF and has started continous readers then can the “FDO” still timeout and go into idle? Can the “FDO” use power-managed queue and forward the request with send and forget?
Or are there any guidelines to implement the “FDO” and “Filter” in such a way that it will work for any function driver that loads on the PDO and provide a clean break in power relationship?
Thanks again,
Nate
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