Do this in DriverEntry:|
// Tell the class driver to initialize the driver.
ntStatus = PcInitializeAdapterDriver (DriverObject,
// Install handlers for various major functions so that this driver
// can publish an ioctl interface. This must be done *after*
// calling PcInitializeAdapterDriver; otherwise, portclass will
// overwrite these vectors.
// The original vectors are saved as globals so that calls that
// are not ours may be passed on to port class.
PcIoctlHandler = DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL];
PcCreateHandler = DriverObject->MajorFunction[IRP_MJ_CREATE];
PcCloseHandler = DriverObject->MajorFunction[IRP_MJ_CLOSE];
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = IoctlHandler;
DriverObject->MajorFunction[IRP_MJ_CREATE] = CreateHandler;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = CloseHandler;
Then, in your individual dispatch routines, determine if it's your IRP or not. If it's not, then call the appropriate PcXXXHandler.
Philip Lukidis wrote:
Hi. I have a 1394 audio device for which I use a portcls style miniport. I'm thinking of porting to avstream in order that surprise removal be properly supported. Question: is there any way to properly and override the dispatch table of the parent driver (specifically, for DeviceIoControl so my control panel can talk to me). KSDEVICE_DISPATCH is available (but not really suitable for me) in WinXP+ only, and at the very least I have to support Win2k also (probably Win98SE and ME as well). I did not see any PcDispacthIrp equivalent, like there is in portcls drivers. Any thoughts? Philip Lukidis PS: So far I always have had a bus driver architecture, i.e. bus driver enumerates the audio driver, and the control panel talked to the bus driver. But this may not always be the case for me. ----- Original Message ----- From: "Waldemar Haszlakiewicz" <waldemar.haszlakiewicz@xxxxxxxx> To: "Matt Gonzalez" <wdmaudiodev@xxxxxxxxxxxxx> Sent: Saturday, March 06, 2004 6:29 AM Subject: [wdmaudiodev] Re: Which type of driverThen again AVStream has lots of stuff implemented already there is lesswriting, but yes morethinking (read breaking your head). BUT when you figure it out everything looks very clean and simple. Anyway if you'll write AVStream driver you'll have to read older driversdocs also (well noteverything) as some things are just upgrades. In short: AVStream hides a lot of stuff from you, so you don't need tobother with them.Waldemar MG> This is exactly what I've been doing. MG> If you want to talk to a 1394 device, you have to make your ownIRPsand send them to theMG> 1394 stack. You will find examples on how to dothis in the 1394samples. Compuware'sMG> DriverWorks also has usefulsample code for talking to 1394. MG> To expose your hardware as an audio device, you need to create akernelstreaming filter.MG> You can try using portclass miniports (like MSVAD)or AVStream. There'salso the older streamMG> class stuff, but you'd bebetter off with AVStream. MG> Portclass is an older model and doesn't handle surprise removalaswell. AVStream isMG> cleaner, but there is no good example code forbuilding an audiodriver. Portclass is perhapsMG> quirkier, but muchbetter documented. MG> Both AVC.sys and 61883.sys weren't useful for our purposes.AVC.sysdoesn't support audioMG> formats. 61883.sys didn't give me enoughcontrol over the streaming. MG> Matt MG> John D. Farmer wrote: MG> Greetings, MG> MG> I'm new to Audio driver developmentand still pretty new to driverdevelopment inMG> general. I am working ona project that needs to stream audio data downto the 1394 Bus,MG> viaAVC.sys and 61883.sys. The overall propose of my project is tosupportFirewire hardware thatMG> will implement the IEC-61883-6 standard (whichMicrosoft says they weregoing to support, butMG> which I have yet to seesupported). I am guessing I am in need of aupper filter driver totakeMG> care of the passing down audio data through the AV/C stack (inplace ofthe avcaudio.sys which IMG> cannot find on my system but found inthe documentation as: Kernel-ModeWDM Audio ComponentsMG> subsection:AVCAudio Class System Driver) and another driver belowavc.sys to beable to packageMG> the audio data up into the 61883-6 standard format onits way down tothe 1394 bus (since I doMG> not believe that 61883.sysdoes not yet support the 61883-6 standard). MG> MG> I have been perusing thedocumentation and this list and there seemsto be alot ofMG> confusion tome on which way would be best to do this. I started bytrying to useMSVAD (which IMG> believe is a Port Class driver), but then I noticed thatMSVAD does notseem to handle IRPs orMG> anything else that would allow meto send data down to the 1394 bus. Ilooked at the MSDN docsMG> and theysaid that Port Class drivers could not be used for thispurpose. I tooka look atMG> this list, and it seems a number of people have been able todo this byimplementing their ownMG> IRPs and URBs (in the case of USB). I've taken note of this andnoticed that it seems to beMG> extremelydifficult to do, and probably not the best way to handle thisproblem.MG> MG> I then started to lookat the AVStream and Stream class drivers. TheAVStream overviewMG> onMSDN that it is a: "multimediaclass driver that supports video-onlystreaming andMG> integratedaudio/video streaming." So does this mean that I cannot useAVStreamto streamMG> audio-only? My last option was the Stream class driver whichthe MSDNdocs seem to suggest thatMG> these driver are almost if nottotally deprecated. MG> MG> I also looked at AV/C Client driver(which I think is a StreamMinidriver) as a option,MG> and it seemed to bealmost what I wanted, but the documentation saysthat the avcstream.sysplaysMG> a part in the AV/C stack, my big problem with this is: I can'tfindavcstream.sys on my systemMG> (I'm running Windows XP) see: IEC-61883Protocol Driver in a ClientDriver Stack in the MSDNMG> documentation. AmI correct in assuming that avcstream.sys handles theAV/C Audio subunit?MG> MG> So as you can probably tell, I am alittle lost and confused on thissubject. If there isMG> anyone out therewho could give this newbie a little guidance, I wouldbe in youreternal debt.MG> MG> Thanks, MG> MG> John Farmer MG> ******************WDMAUDIODEV addresses:Post message: MG> mailto:wdmaudiodev@xxxxxxxxxxxxxxxxxxxxxx: MG> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribeUnsubscribe: MG> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribeModerator: MG> mailto:wdmaudiodev-moderators@xxxxxxxxxxxxxxxx to WDMAUDIODEV****************** 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.de/****************** 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.de/
****************** 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.de/