Hi everybody, I created a custom KMDF driver for my PCIe device and I want to add kernel streaming support for the device.
Do I need to create a separate driver that provides WDM kernel streaming or can I add the kernel streaming interface to my existing KMDF driver?
Thanks.
Typical pattern here is to only have one way to talk to the device function, so probably KS only. If you have now than one function in the device that is a different story
Get Outlook for Androidhttps:
On Sun, Jul 31, 2016 at 3:48 PM -0700, “xxxxx@gmail.com” > wrote:
Hi everybody, I created a custom KMDF driver for my PCIe device and I want to add kernel streaming support for the device.
Do I need to create a separate driver that provides WDM kernel streaming or can I add the kernel streaming interface to my existing KMDF driver?
Thanks.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></https:>
xxxxx@gmail.com wrote:
Hi everybody, I created a custom KMDF driver for my PCIe device and I want to add kernel streaming support for the device.
Do I need to create a separate driver that provides WDM kernel streaming or can I add the kernel streaming interface to my existing KMDF driver?
What is the hardware, generally speaking? What is the interface into
your existing KMDF driver? Do you just have some custom diagnostic
applications?
AVStream and KMDF are not necessarily a good fit. Much of what KMDF
provides is already provided by AVStream. AVStream handles the IRP
dispatching for you. You don’t deal with it directly.
If you look at the AVStream samples (avshws and avssamp), you can see
there is a relatively generic part that handles the format negotiation,
and then there’s a hardware specific part, implemented by simulations in
the sample. Generally, what you need to do is figure out what parts of
your KMDF driver are actually managing the streaming, and use that to
replace the hardware simulation in the samples.
It’s possible you might still want to use KMDF in its “miniport” mode,
where it cedes control of the dispatching. That, at least, would let
you continue to use the DMA abstraction.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It’s a video/audio capture/playback PCIe device which we have a custom
interface for.
Most users use the custom interface, but we do get asked for KS quite a bit.
I was hoping to avoid having to support two separate drivers for the same
device.
Users will only be able to use either the custom interface or KS, but I was
hoping to be able to set the driver into a certain mode (either custom or
KS).
Just trying to avoid confusion for customers by providing two drivers.
I was thinking that KS could be the default interface and if users start
talking to the device via the custom interface it could change it’s “mode”
from KS to customer.
Does this thinking make any sense at all?
On 2 August 2016 at 10:14, Tim Roberts wrote:
> xxxxx@gmail.com wrote:
> > Hi everybody, I created a custom KMDF driver for my PCIe device and I
> want to add kernel streaming support for the device.
> > Do I need to create a separate driver that provides WDM kernel streaming
> or can I add the kernel streaming interface to my existing KMDF driver?
>
> What is the hardware, generally speaking? What is the interface into
> your existing KMDF driver? Do you just have some custom diagnostic
> applications?
>
> AVStream and KMDF are not necessarily a good fit. Much of what KMDF
> provides is already provided by AVStream. AVStream handles the IRP
> dispatching for you. You don’t deal with it directly.
>
> If you look at the AVStream samples (avshws and avssamp), you can see
> there is a relatively generic part that handles the format negotiation,
> and then there’s a hardware specific part, implemented by simulations in
> the sample. Generally, what you need to do is figure out what parts of
> your KMDF driver are actually managing the streaming, and use that to
> replace the hardware simulation in the samples.
>
> It’s possible you might still want to use KMDF in its “miniport” mode,
> where it cedes control of the dispatching. That, at least, would let
> you continue to use the DMA abstraction.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
Tim Bragulla wrote:
It’s a video/audio capture/playback PCIe device which we have a custom
interface for.
Most users use the custom interface, but we do get asked for KS quite
a bit.
Do you literally get asked for KS support, or do you get asked for
DirectShow support?
It’s quite possible to create a user-mode DirectShow source filter that
registers itself as a capture source, and have the user-mode filter call
your custom driver interface. That lets you offer DirectShow without
doubling the kernel effort.
I was hoping to avoid having to support two separate drivers for the
same device.
Users will only be able to use either the custom interface or KS, but
I was hoping to be able to set the driver into a certain mode (either
custom or KS).
Just trying to avoid confusion for customers by providing two drivers.
I was thinking that KS could be the default interface and if users
start talking to the device via the custom interface it could change
it’s “mode” from KS to customer.Does this thinking make any sense at all?
Not so much. KS video sources are accessed through APIs like the
CLSID_SystemDeviceEnum enumerator. Users don’t call CreateFile
directly. And because AVStream intercepts all of the I/O dispatching,
it takes magic to interfere. Plus, your KS driver would have to be
registered in Class=Image, which offers certain guarantees that your
custom interface doesn’t satisfy.
You certainly don’t want to have two drivers touching the hardware.
Another alternative is to have a KS shell that calls into your existing
custom driver, but that’s pretty much the kernel equivalent of the
DirectShow source filter. It has little to offer.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.