In Short: I need to detect hotplug events of my USB CDC device by PID/VID and get the corresponding virtual COM port which was created by Windows in Visual C++ and in the end create a dll.
I have a USB CDC device which I need to be notified of when connected/disconnected on Windows. My approach is to use RegisterDeviceNotification and an "invisible" Window to receive WM_DEVICECHANGE notifications. This part is working so far.
Now as far as I found out I need to get the list of USB devices that is plugged, iterate over it and filter out the devices with my PID/VID? I assume that I am then able to get more informations about the device including the COM port?
Is the only way to achieve my goal to use SetupDi calls in setupapi.h? Is using WDK / DDK the only way to achieve my goal?
As soon as that is working I open-source it on http://github.com/vinzenzweber/USBEventHandler. The Mac version is available already!
After digging through tons of useless documentation at msdn and some debugging I found the missing link: SetupDi calls in setupapi.h: More infos as well as source code for Mac and Windows can be found in my USBEventHandler project at github.com with sources for Mac and Windows.
Related
I'm trying to write a custom USB MIDI driver for macOS. I found a few projects online that are based on some old Apple Sample code, one example linked below.
https://github.com/ysalathe/GenericUSBMIDI
The project seems sensible and works to an extent, but I'm having a problem with it. I hoped someone with experience of the macOS CFPlugin based MIDI driver system might be able to help me...
Steps to recreate issue:
Copy the project's product (GenericUSBDriver.plugin) to ~/Library/Audio/MIDI Drivers
Connect my MIDI device via USB
Open Audio MIDI setup and select show MIDI studio
MIDI studio now shows an icon with the name from my MIDI device's USB descriptor. However, my log shows that my driver failed in USBDevice::OpenAndConfigure when USBDeviceOpen() returns kIOReturnExclusiveAccess (USBDevice.cpp line: 189).
require_noerr((*mPluginIntf)->USBDeviceOpen(mPluginIntf), errexit);
Then after clicking 'Rescan MIDI' my driver loads successfully and a 2nd icon appears in MIDI studio with the driver specified name, but the original icon from step 4 persists. So, I now have 2 icons representing the attached device in MIDI Studio.
Googling things like: 'USBDeviceOpen() kIOReturnExclusiveAccess MIDI' gets various 'Apple Mailing Lists' hits around a decade old, but with no solutions.
It seems to me the standard Apple USB MIDI driver is grabbing my device and causing my driver to fail with kIOReturnExclusiveAccess on USBDeviceOpen(). Then after clicking 'Rescan MIDI' the Apple driver has let go, which allows my driver to load.
My device has an asynchronous USB audio interface, and a MIDI interface with 2 bidirectional ports.
My main question is...
How can I get the Apple MIDI system to select my driver after matching on USB VID/PID instead of the standard Apple driver?
but also...
Does anyone know of any docs or books that can help me? Is there a newer/ better way perhaps?
My driver renames the MIDI ports to something more intuitive for our users, macOS seems to ignore the names in the jack descriptors unlike Windows. Is there another way to do this?
I've been reading the book "OS X and iOS Kernel Programming", but while being very interesting hasn't shed any light on this problem. I can get their USB driver example to match on my USB device's MIDI interface and load, but there seems no obvious way for that to then influence the CFPlugin choice.
I have created a fake usb flash driver driver in Windows that will fake Windows into thinking that a new hardware device is attached. I have also found the APIs that allow me to enumerate the hardware attached (so I know which device is my fake driver).
The problem is I only want to attach the hardware when my program is running, and I don't want it to be accessible when my program is not running.
How can I programmatically add this hardware or enable/disable this driver? Someone suggested the right nomenclature is "load/unload".
Using VC++ with Windows APIs on Windows 7 and higher.
Try the C++ class wrapper to load/unload device drivers from code project.
I have been searching through how to do gamepad and joystick support on Mac for some days and all resources that I found seems to suggest a pre-installed driver along with using Apple's HID API, which works.
The drawback about this approach is that each joystick and gamepad will require another kernel extension to be loaded, so it can be recognized by HID manager, or at least a code less Info.plist saying it conforms to the earlier installed driver. For instance, when I have an 360 Xbox driver KEXT in house, the Xbox controller from Microsoft will work, but not the Logitech one (I tried F710).
As Apple suggests the application that uses a gamepad or joystick should be able to do themselves at user space without introducing any KEXT stuff. Is there a way to do it?
The thing I had in mind was something like using IORegistry or IOUSB API to get the device when they get plugged in (USB Prober shows it at least). Then somehow get the description of the device, then use that description to register the device as a HID one. Then the whole HID manager can be used.
Am I on the right track? Or is there any other way to do this?
Since IOKit API actually provided keywords like kHIDUsage_GD_Joystick, and there's an ForceFeedback.h library, I suppose Apple designed their HID API with joystick and force feedback in mind. That's the slim hope I had that this might work.
Some reference documentation and open source project:
Colin Munro's 360 driver
HID API Documents
DDHID Project
After revisiting this, I found out the solution to be operating directly on the file descriptors of the device. libusb is an excellent library which greatly simplify your life on this and they have Mac supported.
xboxdrv link is a great example on how to operate on file socket using libusb.
In pseudo code, it should look like this:
enumerate device
detect kernel driver and detach it if possible
open device
file off a initial transfer
wait on the callback function to handle msg and error properly
start run loop or select on fd to call libusb_event_handle
Check libusb for more info link.
I have developed a USB device that communicates with linux over a simple but proprietary interface and some custom Linux drivers. My goal is to port this to Windows without writing windows drivers. What I would like to do is find an open source or inbuilt class driver for windows that would look like a COM port in Windows. Then I would tailor the embedded software to match what ever protocol and descriptors the virtual COM port expects to see.
The idea would be that I could plug my device in to a Windows machine and a relatively high speed COM port would appear with out me having to develop Windows drivers for it.
I have been looking at the USB CDC (Communications Device Class) documentation and it looks promising, but I don't know which sub interface would be best to use so that it would show up as a COM port.
Has anyone here done any work like this before or could provide some insight?
Specifically:
Are there virtual COM drivers "built in" to windows or would I need a 3rd party driver.
Which CDC sub class should I use for simple RS232 emulation (No need for modem AT commands, etc)
Is there a better option to do what I am trying to do.
Thanks
There is a USB-to-serial driver built in to Windows that will do what you want. It is called usbser.sys:
http://support.microsoft.com/kb/837637
You will have to write an INF file and distribute that to your users, but that will not be too hard because it is only a few kilobytes of text and you can find examples online.
I'm not aware of any great documentation for this driver by Microsoft, so my advice would be to find some other device that uses it, such as Pololu Wixel, and copy what they did.
Here are the device descriptors we used and the special control tranfers we had to implement:
https://github.com/pololu/wixel-sdk/blob/master/libraries/src/usb_cdc_acm/usb_cdc_acm.c
You can see our INF file, wixel_serial.inf, by downloading the software and looking in the drivers folder:
http://www.pololu.com/docs/0J46/3.a
(There are other files in there that are not necessary for you.)
You can also look at the Arduino Uno because they use the same driver.
Whatever you do, please don't use our USB Vendor ID in your product! You need to get your own.
Update: In Windows 10, you don't need an INF file anymore because of the new usbser.inf driver that comes with Windows.
If you are using a UART you can easily interface it to a FTDI USB chip like http://www.ftdichip.com/Products/ICs/FT232R.htm or a Prolific like http://www.prolific.com.tw/eng/products.asp?id=59
For development, prototype and testing I have half dozen of these laying around http://www.pololu.com/catalog/product/391
I connect it directly to the UART pins on AVR and 8051 micros.
I am looking for a programmically API on how to restart any device that allows enable/disable in the device manager,
such as Audio devices and Network adapter
You will have to use SetupApi / ConfigManager API. But be aware that under x64 you app. must be also x64 to enable/disable device (so you cannot do it in Delphi directly right now - first I thought that it's a problem with file/registry redirection for x86-app under x64, but it didn't help). Device enumeration works fine. There was something about it in one article on MSDN but I cannot find it right now. I've made FP/Lazarus x64 application for enable/disable devices under x64 OS.
You can download WDK and look for source code of DevCon (C:\WinDDK\7600.16385.1\src\setup\devcon). In cmds.cpp there is function ControlCallback which enables/disables device using SetupApi). But first you need to enumerate device classes (by GUID or ClassName), and then enumerate device instances or open device by DeviceInstanceId string. It's in C but it should be easy to learn how to use that API.
Not sure what you are doing, but maybe it would be easier to use that devcon.exe (don't know if license permits it) and enable/disable devices by it?
I have no experience with it but I think you can use the DeviceIoControl API.