Does AVStream sets the completion routine as well when
KsInitializeDriver is called, or it should be set by minidriver via
IoSetCompletionRoutine?
Thank you.
Petriaev, Yuri wrote:
Does AVStream sets the completion routine as well when
KsInitializeDriver is called, or it should be set by minidriver via
IoSetCompletionRoutine?
Your question doesn’t make sense. A completion routine is not a global
thing. Each IRP that you submit has its own completion routine.
AVStream isn’t involved.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Dear Team,
Do I have to provide usual initializations for USB minidriver that take
place in DriverEntry.
Doesn’t AVStream makes similar initializations via KsInitializeDriver
call?
Where if any of this sort of initialization should be implemented for
the USB AVStream minidriver?
Sample:
DriverObject->MajorFunction[IRP_MJ_CREATE] = DispatchCreate;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = DispatchClose;
DriverObject->MajorFunction[IRP_MJ_CLEANUP] = DispatchCleanup;
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DispatchControl;
DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] =
DispatchInternalControl;
DriverObject->MajorFunction[IRP_MJ_POWER] = DispatchPower;
DriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnp;
DriverObject->MajorFunction[IRP_MJ_SYSTEM_CONTROL] = DispatchWmi;
Yuri
Petriaev, Yuri wrote:
Do I have to provide usual initializations for USB minidriver that
take place in DriverEntry.
The typical USB device does not do any initialization in DriverEntry.
Instead, the initialization is done in either AddDevice or in the PnP
StartDevice callback.
Doesn’t AVStream makes similar initializations via KsInitializeDriver
call?
AVStream initializes its own data structures, and sets up the dispatch
entry points so that they point into ks.sys. Then, when requests
arrive, ks.sys calls back the minidriver entry points declared in your
device, filter, and pin descriptors.
Where if any of this sort of initialization should be implemented for
the USB AVStream minidriver?Sample:
DriverObject->MajorFunction[IRP_MJ_CREATE] = DispatchCreate;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = DispatchClose;
DriverObject->MajorFunction[IRP_MJ_CLEANUP] = DispatchCleanup;
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DispatchControl;
DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] =
DispatchInternalControl;DriverObject->MajorFunction[IRP_MJ_POWER] = DispatchPower;
DriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnp;
DriverObject->MajorFunction[IRP_MJ_SYSTEM_CONTROL] = DispatchWmi;
All of that is done by KsInitializeDriver. DriverEntry in the typical
AVStream driver does nothing other than call KsInitializeDriver. Have
you looked through the samples? They certainly show the way things are
“usually” done in an AVStream driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I am using avshws sample from DDK AVStream samples.
It is using a pin-centric processing.
When I ran debugger I do not see any of the pin DispatchCreate, Process
and other events ever being called.
When does the pin creation and other methods of the KSPIN_DISPATCH are
being invoked?
Thank you Tim for your reply.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 2008-04-04 11:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB AVStream minidriver
Petriaev, Yuri wrote:
Do I have to provide usual initializations for USB minidriver that
take place in DriverEntry.
The typical USB device does not do any initialization in DriverEntry.
Instead, the initialization is done in either AddDevice or in the PnP
StartDevice callback.
Doesn’t AVStream makes similar initializations via KsInitializeDriver
call?
AVStream initializes its own data structures, and sets up the dispatch
entry points so that they point into ks.sys. Then, when requests
arrive, ks.sys calls back the minidriver entry points declared in your
device, filter, and pin descriptors.
Where if any of this sort of initialization should be implemented for
the USB AVStream minidriver?
Sample:
DriverObject->MajorFunction[IRP_MJ_CREATE] = DispatchCreate;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = DispatchClose;
DriverObject->MajorFunction[IRP_MJ_CLEANUP] = DispatchCleanup;
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DispatchControl;
DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] =
DispatchInternalControl;DriverObject->MajorFunction[IRP_MJ_POWER] = DispatchPower;
DriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnp;
DriverObject->MajorFunction[IRP_MJ_SYSTEM_CONTROL] = DispatchWmi;
All of that is done by KsInitializeDriver. DriverEntry in the typical
AVStream driver does nothing other than call KsInitializeDriver. Have
you looked through the samples? They certainly show the way things are
“usually” done in an AVStream driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Petriaev, Yuri wrote:
I am using avshws sample from DDK AVStream samples.
It is using a pin-centric processing.
In my experience, this is the best choice in most cases.
When I ran debugger I do not see any of the pin DispatchCreate, Process
and other events ever being called.When does the pin creation and other methods of the KSPIN_DISPATCH are
being invoked?
The filter and its pins get created when you create a filter graph and
insert an instance of the device into that filter graph. The raw driver
just creates a filter FACTORY, which allows filters to be created later,
when they are needed.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Dear Team,
I have a StartInterruptUrb function that issues a read to the interrupt
pipe.
My understanding is that in USB drivers such interrupt function would be
called in PNPStart.
Since this is AVStream minidriver, should it be called by capture pin
when KSSTATE is KSSTATE_RUN instead?
Thank you.
Petriaev, Yuri wrote:
I have a StartInterruptUrb function that issues a read to the
interrupt pipe.My understanding is that in USB drivers such interrupt function would
be called in PNPStart.
Well, in a non-capture USB driver, you would start the URB cycling when
you wanted to start streaming. PnPStart is the right place for some
kinds of drivers, but not necessarily all.
It is unusual for a capture device to use an interrupt pipe. What do
you use that for?
Since this is AVStream minidriver, should it be called by capture pin
when KSSTATE is KSSTATE_RUN instead?
You should fire up your streaming resources during the transition to
KSSTATE_ACQUIRE. That’s the reason it exists. That way, by the time
you transition to KSSTATE_PAUSE or KSSTATE_RUN, frames should already be
flowing and there won’t be any additional delay.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
My camera has two end points, BULK and INTERRUPT.
I was thinking of polling an interrupt endpoint, just how its usually
done with USB Drivers that use interrupt service routine as the
completion routine. Probably a bad idea for there is “Process” function
in CapturePin.
The avshws sample uses AcquireHardwareResources to fire up streaming
resources during the transition to KSSTATE_ACQUIRE. I am quite pazzled
how to fire streaming resources on USB (with actual hardware)?
Thank you.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 2008-04-07 1:05 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB AVStream minidriver
Petriaev, Yuri wrote:
I have a StartInterruptUrb function that issues a read to the
interrupt pipe.My understanding is that in USB drivers such interrupt function would
be called in PNPStart.
Well, in a non-capture USB driver, you would start the URB cycling when
you wanted to start streaming. PnPStart is the right place for some
kinds of drivers, but not necessarily all.
It is unusual for a capture device to use an interrupt pipe. What do
you use that for?
Since this is AVStream minidriver, should it be called by capture pin
when KSSTATE is KSSTATE_RUN instead?
You should fire up your streaming resources during the transition to
KSSTATE_ACQUIRE. That’s the reason it exists. That way, by the time
you transition to KSSTATE_PAUSE or KSSTATE_RUN, frames should already be
flowing and there won’t be any additional delay.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Petriaev, Yuri wrote:
My camera has two end points, BULK and INTERRUPT.
But what information travels on those two endpoints? How is the
streaming data sent, and what goes on the other pipe?
I was thinking of polling an interrupt endpoint, just how its usually
done with USB Drivers that use interrupt service routine as the
completion routine. Probably a bad idea for there is “Process” function
in CapturePin.
No, you’re thinking about this correctly. The Process function is
called asynchronously with the USB stream. In my USB AVStream drivers,
the Process routine does almost nothing, other than make a clone of the
leading edge to make sure the buffer doesn’t go away. The real work
happens in the URB completion handler.
Remember that “Process” is just giving your driver the OPPORTUNITY to do
work. You aren’t obligated to return anything at that point. The
stream will advance when you delete the last clone of the leading edge
frame.
The avshws sample uses AcquireHardwareResources to fire up streaming
resources during the transition to KSSTATE_ACQUIRE. I am quite pazzled
how to fire streaming resources on USB (with actual hardware)?
I do it just as you describe. The device’s AcquireHardwareResources
method calls a routine in my “device abstraction class”, which is the
only class that knows about USB. That class creates the URB objects and
starts them cycling.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
This is a very old camera and manufacturer does not provide any support.
It has OV9620 (color) high-performance 1.3 mega-pixel camera chip for
digital still image and video camera products.
The Interrupt end point has max. packet size = 0x0004, and bulk =
0x0200.
Could that mean that bulk is in fact used for image?
Thank you.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 2008-04-07 1:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB AVStream minidriver
Petriaev, Yuri wrote:
My camera has two end points, BULK and INTERRUPT.
But what information travels on those two endpoints? How is the
streaming data sent, and what goes on the other pipe?
I was thinking of polling an interrupt endpoint, just how its usually
done with USB Drivers that use interrupt service routine as the
completion routine. Probably a bad idea for there is “Process”
function
in CapturePin.
No, you’re thinking about this correctly. The Process function is
called asynchronously with the USB stream. In my USB AVStream drivers,
the Process routine does almost nothing, other than make a clone of the
leading edge to make sure the buffer doesn’t go away. The real work
happens in the URB completion handler.
Remember that “Process” is just giving your driver the OPPORTUNITY to do
work. You aren’t obligated to return anything at that point. The
stream will advance when you delete the last clone of the leading edge
frame.
The avshws sample uses AcquireHardwareResources to fire up streaming
resources during the transition to KSSTATE_ACQUIRE. I am quite pazzled
how to fire streaming resources on USB (with actual hardware)?
I do it just as you describe. The device’s AcquireHardwareResources
method calls a routine in my “device abstraction class”, which is the
only class that knows about USB. That class creates the URB objects and
starts them cycling.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Petriaev, Yuri wrote:
This is a very old camera and manufacturer does not provide any support.
It has OV9620 (color) high-performance 1.3 mega-pixel camera chip for
digital still image and video camera products.
The OV9620 is just a sensor. It doesn’t have a USB interface, so the
USB stuff is coming from some other chip.
The Interrupt end point has max. packet size = 0x0004, and bulk =
0x0200.
Could that mean that bulk is in fact used for image?
Definitely. The original USBCAMD library used an interrupt “sync pipe”
alongside the streaming pipe, for transmitting information like
start-of-frame and camera errors. It’s possible that’s what you’re
seeing here. All of the USB cameras I’ve worked on have moved to a
model where that kind of information is transmitted in the streaming
data, because it was too inconvenient to keep the separate pipes in sync.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I think this assesment is correct. Not that it makes me feel better…
Does that mean that I should tie my completion with bulk end point?
Sample initializes CHardwareSimulation in PNPStart. Should the same
initialization and uses of m_HardwareSimulation remain for it has start,
stop, pause and other functions…?
Thank you Tim!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 2008-04-07 3:04 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB AVStream minidriver
Petriaev, Yuri wrote:
This is a very old camera and manufacturer does not provide any
support.
It has OV9620 (color) high-performance 1.3 mega-pixel camera chip for
digital still image and video camera products.
The OV9620 is just a sensor. It doesn’t have a USB interface, so the
USB stuff is coming from some other chip.
The Interrupt end point has max. packet size = 0x0004, and bulk =
0x0200.
Could that mean that bulk is in fact used for image?
Definitely. The original USBCAMD library used an interrupt “sync pipe”
alongside the streaming pipe, for transmitting information like
start-of-frame and camera errors. It’s possible that’s what you’re
seeing here. All of the USB cameras I’ve worked on have moved to a
model where that kind of information is transmitted in the streaming
data, because it was too inconvenient to keep the separate pipes in
sync.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Petriaev, Yuri wrote:
I think this assesment is correct. Not that it makes me feel better…
Does that mean that I should tie my completion with bulk end point?
I’m not sure what you mean. You will have to get specs for the chip
that is handling the USB interface, otherwise you’re just guessing. You
will certainly have to copy the data into the leading edge frame in the
bulk URB completion routine. If there is enough information in the bulk
stream for you to detect the end of a frame, then you can skip the
interrupt pipe and commit the frames there as well.
Sample initializes CHardwareSimulation in PNPStart. Should the same
initialization and uses of m_HardwareSimulation remain for it has start,
stop, pause and other functions…?
You have to decide what makes sense to you. I created my own hardware
abstraction class to replace CHardwareSimulation, because I could never
ship a driver where real hardware was driven by a class called
“CHardwareSimulation”. My hardware abstraction class certainly gets
created in PnPStart (because I have to be able to handle properties
before we start streaming), but the URB handling doesn’t start until needed.
That’s really the key observation. Don’t do anything any earlier than
you really need to.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I am sure now that bulk is used for video data, and interrupt is for the
snap shot button.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 2008-04-07 3:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB AVStream minidriver
Petriaev, Yuri wrote:
I think this assesment is correct. Not that it makes me feel better…
Does that mean that I should tie my completion with bulk end point?
I’m not sure what you mean. You will have to get specs for the chip
that is handling the USB interface, otherwise you’re just guessing. You
will certainly have to copy the data into the leading edge frame in the
bulk URB completion routine. If there is enough information in the bulk
stream for you to detect the end of a frame, then you can skip the
interrupt pipe and commit the frames there as well.
Sample initializes CHardwareSimulation in PNPStart. Should the same
initialization and uses of m_HardwareSimulation remain for it has
start,
stop, pause and other functions…?
You have to decide what makes sense to you. I created my own hardware
abstraction class to replace CHardwareSimulation, because I could never
ship a driver where real hardware was driven by a class called
“CHardwareSimulation”. My hardware abstraction class certainly gets
created in PnPStart (because I have to be able to handle properties
before we start streaming), but the URB handling doesn’t start until
needed.
That’s really the key observation. Don’t do anything any earlier than
you really need to.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Petriaev, Yuri wrote:
I am sure now that bulk is used for video data, and interrupt is for the
snap shot button.
I know that this is an older design, so it doesn’t do any good at all to
whine about it, but that’s not going to stop me.
In my view, this is a short-sighted design. A snapshot button is a
relatively rarely used feature, but this designed requires that you
permanently commit a percentage of your USB bandwidth to support this
one very specific feature. In the last couple of designs I’ve done,
we’ve embedded the snapshot bit either as the low-order bit of the first
pixel of the frame, or as a bit somewhere in the image header or the
SAV/EAV codes. There has to be some kind of header somewhere in the
image to tell me that “this is the start of the new frame”, and that’s
the perfect place to embed a snapshot bit.
One client tried to argue that this wasn’t enough, because the snapshot
button was asynchronous, but that’s just silly. If the user presses the
snapshot button in mid-frame, I’m not going to start re-routing pixels
in the middle of the scanline to the snapshot sink. I won’t take any
action until the frame ends, so why not associate the snapshot
information with the frame transition?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
Following your statement regarding doing anything any earlier than
really needed, is obtaining device, configuration and interface
descriptions as well as setting configuration should be still performed
at PnpStart, right after call to KsCreateFilterFactory or later on when
m_HardwareSimulation->Start is called?
Thank you.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 2008-04-08 1:00 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB AVStream minidriver
Petriaev, Yuri wrote:
I am sure now that bulk is used for video data, and interrupt is for
the
snap shot button.
I know that this is an older design, so it doesn’t do any good at all to
whine about it, but that’s not going to stop me.
In my view, this is a short-sighted design. A snapshot button is a
relatively rarely used feature, but this designed requires that you
permanently commit a percentage of your USB bandwidth to support this
one very specific feature. In the last couple of designs I’ve done,
we’ve embedded the snapshot bit either as the low-order bit of the first
pixel of the frame, or as a bit somewhere in the image header or the
SAV/EAV codes. There has to be some kind of header somewhere in the
image to tell me that “this is the start of the new frame”, and that’s
the perfect place to embed a snapshot bit.
One client tried to argue that this wasn’t enough, because the snapshot
button was asynchronous, but that’s just silly. If the user presses the
snapshot button in mid-frame, I’m not going to start re-routing pixels
in the middle of the scanline to the snapshot sink. I won’t take any
action until the frame ends, so why not associate the snapshot
information with the frame transition?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Petriaev, Yuri wrote:
Following your statement regarding doing anything any earlier than
really needed, is obtaining device, configuration and interface
descriptions as well as setting configuration should be still performed
at PnpStart, right after call to KsCreateFilterFactory or later on when
m_HardwareSimulation->Start is called?
It depends on your needs, but in most cases you’ll need access to the
device earlier than Start. In my case, part of my property set is
determined by items in the descriptors, so I create my USB hardware
abstraction class at PnPStart time. The constructor for the abstraction
class fetches the descriptors and selects the configuration.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The AVStream KSPIN_DISPATCH method SetDeviceState that is used to run,
pause, stop and aquire device does not have IRP as one of its arguments.
How can I get IRP to start I/O?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 2008-04-08 4:48 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB AVStream minidriver
Petriaev, Yuri wrote:
Following your statement regarding doing anything any earlier than
really needed, is obtaining device, configuration and interface
descriptions as well as setting configuration should be still
performed
at PnpStart, right after call to KsCreateFilterFactory or later on
when
m_HardwareSimulation->Start is called?
It depends on your needs, but in most cases you’ll need access to the
device earlier than Start. In my case, part of my property set is
determined by items in the descriptors, so I create my USB hardware
abstraction class at PnPStart time. The constructor for the abstraction
class fetches the descriptors and selects the configuration.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Petriaev, Yuri wrote:
The AVStream KSPIN_DISPATCH method SetDeviceState that is used to run,
pause, stop and aquire device does not have IRP as one of its arguments.
How can I get IRP to start I/O?
You create one. Have you really never used IoAllocateIrp?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.