Yes, you have to add your own handlers after calling
PcInitializeAdapter. You don't have to save the original handler,
although that works. You can simply call PcDispatchIrp if the IRP
isn't handled by your code, as discussed in the DDK documentation.|
You have to add handlers for create, ioctl, and close IRPs. You will also need to create your own interface using IoRegisterDeviceInterface. Your handlers need to distinguish between IRPs meant for KS and IRPs meant for your interface. You then use the setup API to find and open your interface.
I've used this method with great success with several different audio drivers. You can do the same thing with AVStream.
The technique you describe of creating a custom KS property will also work. As far as what is the "RIGHT" method to use, I'm not sure how you'd make that determination. Either way, there are a fair number of hoops to jump through. I always thought that handling KS properties was a pain and hard to debug since KS itself is such a black box. On the other hand, adding your own ioctl handler means you have to create your own WDM interface, and write code to distinguish between IRPSs meant for your code and IRPs meant for KS/Portcls.
If you add a custom KS property, it's still an ioctl that's being sent to your driver. It's just being filtered through the KS code. I'm not sure you'd see a difference in performance.
****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/On Sat, Jan 31, 2009 at 06:18:35PM -0800, Vipin Kumar wrote:i am using a MSVAD Simple as a base,( so portcls wavecyclic is the type). Moreover, as i have told earlier, i have already done DriverObject->MajorFunction [IRP_MJ_DEVICE_CONTROL] = IoCtlHandler; for IRP_ MJ_CREATE,How did you do that? The DriverEntry for MSVAD, like all port class devices, calls PcInitializeAdapter. THAT routine sets up all of the dispatch entry points for you. Port class is ALREADY handling IRP_MJ_CREATE. You can't just override it, because you'll lost the class driver support. This is a kernel streaming driver. The KS framework is already opening and closing your driver, and sending you specially formatted ioctls to handle the KS interfaces. You need to work within that framework. The RIGHT way to do this is to add another custom property to handle your unique needs. Then, your application can use CLSID_SystemDeviceEnum to find your driver and get the IBaseFilter interface. From there, you can fetch an IKsControl interface, and send property requests to your heart's content. Before I get a possible/impossible reply, I will state that it is possible for you to intercept IRP_MJ_DEVICE_CONTROL requests on your own, after port class has done its setup. You have to save the original IRP_MJ_DEVICE_CONTROL handler, so you can forward to it any requests that you don't recognize. You still have the problem of how to open the device, given the KS framework. Overall, I have to think it would be better for you to do this through properties.