Writing Lower Filter driver for UVC (Usbvideo.sys)

NTDEV
21

If the op really needs to provide continuous but delayed service then a mux design pattern would do that. It is fairly complicated to implement. The multiplexer design is typically used for disks or network devices to provide redundancy.

22

I agree that's not impossible, but in this case we have someone who doesn't understand how driver stacks are constructed, and is simply attacking the problem in the wrong way. A mux driver would be INCREDIBLE overkill.

23

Thanks Tim, for the reply.
As matter of fact, I do understand how the Windows driver I/O Stack works.

I'm trying to collect as much information to confirm that Lower Filter driver for UVC camera device cannot retry the failed command if the device goes offline during a FW switch, this is Something I confirmed by creating a filter driver and testing with the hardware doing a switch when camera app is opened. I noticed that Filter driver unloaded and loaded back.

24

Thanks for all the replies.
One question pending is why the filter driver is not getting Dispatch IRP_MJ_PNP passthrough callbacks.

Registered a passthrough callback in DriverEntry.
for (UINT32 i = 0; i <= IRP_MJ_PNP; i++) {
DriverObject->MajorFunction[i] = DispatchPassThrough;
}

//
// Create a framework driver object to represent our driver.
//
status = WdfDriverCreate(DriverObject,
RegistryPath,
WDF_NO_OBJECT_ATTRIBUTES,
&config,
&hDriver);

I'm not seeing the callback method called.
NTSTATUS
DispatchPassThrough(
In PDEVICE_OBJECT DeviceObject,
In PIRP Irp
)
{
PURB pUrb;
NTSTATUS status;
PIO_STACK_LOCATION irpStack;

DbgPrint("%s: Line %d \n", __FUNCTION__, __LINE__);

irpStack = IoGetCurrentIrpStackLocation(Irp);

DbgPrint("%s: %d %d \n", __FUNCTION__, irpStack->MinorFunction, 
    irpStack->MajorFunction);

Any inputs and suggestions will be helpful.
Thanks,
Prasad

25

Because you did that in the wrong order. WdfDriverCreate sets up the MajorFunction list on your behalf, so it can do the dispatching, thereby overriding whatever you stored in there.

Why are you overriding the MajorFunction list? You were already getting KMDF dispatch calls, weren't you? That's what is shown up above.

26

This callback for InternalDeviceControl is working. Wanted to check if i can get the IRP_MJ_PNP request callback in this Method? Or I need to setup a separate passthrough callback as mentioned in my previous post?

27

WDFIOQUEUEs are for read, write, and IOCTLs. PnP is handled entirely by KMDF and exposed to you through a set of callbacks. What higher level problem are you trying to solve by processing the underlying pnp irp? You can an register a WDM pre processing callback to get access to the pnp irp...BUT you if your goal is to prevent the removal of the device or delay stall the removal of the device, that is not possible (KMDF or not)

28

There are KMDF callbacks for many PnP requests. They just don't go through the I/O queues. Power-Up Sequence for a Function or Filter Driver - Windows drivers | Microsoft Learn

I don't like the direction this thread is taking. I get the sense that you don't believe what you have been repeatedly told in this thread, and you're going to try to achieve your misplaced goal through hackery, without understanding how KMDF and PnP work.

29

See WdfDeviceInitAssignWdmIrpPreprocessCallback.