[wdmaudiodev] Re: StartDevice Empty Resource List?
- From: Max K <xaseriii@xxxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Sun, 9 Jun 2013 20:58:43 +0200
Hi guys,
thanks for your reply Tim, your answers are always short but informative :)
Over the last days, I have made huge progress in understanding KS and
especially PortCls. I still can't however create a MIDI port that can be found
using midiInGetDevCaps. I am probably missing something very important in
correct startup of the driver.
Apparently, you don't necessarily need to have interfaces defined in your inf
files. I looked at a couple of inf files of my midi keyboards here and none of
them defines any interfaces (except one driver, which specifies his topology
interface).
MSDN says: "When enumerating MIDI input or output devices through the Windows
Multimedia midiInXxx or midiOutXxx functions, an application can see only WDM
devices whose miniport drivers expose MIDI pins."
(http://msdn.microsoft.com/de-de/library/windows/hardware/ff537520%28v=vs.85%29.aspx)
right, I have done that, I pretty much use the Pin factory from the DMusUart
sample, that should do just fine for now.
I wonder, when a Midi Stream in the miniport is supposed to be created and by
who. Will the OS call the newStream function when the driver is completely
loaded or when a client connects to the midi port? Or do I need to create it in
some kind of ISR? I haven't worried too much about the Interrupts as it wasn't
well documented in the audio section (the only thing I found there was how to
notify the Port that a hardware interrupt was triggered) and the sample didn't
seem to do very much in the ISRs.
Any ideas would be great,
Max
Date: Wed, 5 Jun 2013 14:50:50 -0700
From: timr@xxxxxxxxx
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: StartDevice Empty Resource List?
Max K wrote:
okay after more programming and research I have now my own,
specialized, version based on Eugenes code and the devcon
install sample code, i used a few more updated funtions. However
I couldn't notice any part where a PDO is created, maybe in the
SetupDiCallClassInstaller function?
Yes. "Devcon install" creates a structure in memory, and
SetupDiCallClassInstaller creates the kernel structures that result
in your driver being loaded.
>> I use DPInst to do my pre-installs
well aparently the Class Installer called by devcon copies the
.sys to system32/drivers already, so what use DPInst for?
If you use "devcon install" you don't need DPInst. However, you
can't distribute devcon.exe with your driver packages, so when you
want this to be used by other people, you'll need something else.
So a few new questions pop up:
Also you mentioned that you could use either the PNP or a
Service Manager, which one is preferred?
The multimedia device classes require the use of device interfaces.
Those will only work in a PnP driver.
Is there a tool that i can use to display the PDOs
on the various busses?
The registry has them all, but it includes devices that existed in
the past but don't right now. You can get this information from the
kernel debugger.
Do I need to recreate the PDO on each system start?
The device that "devcon install" creates is tucked in the registry
in CurrentControlSet\Enum, and should be re-created on each boot.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Other related posts:
