[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: