This is the closest I could fine but it enumerates all usb devices. In my case I am handling WM_DEVICECHANGE event where I handle arriving usb device and want to gather extended information from this device when its plugged in other than the simple USB strings that contains the vid and pid.
I can't find any resource on it, is that possible?
I am using windows 7 and qt 5.5
Related
I am trying to connect a Bluetooth Low Energy enabled MIDI hardware to wirelessly send data to a Windows PC and get it to detect as a MIDI device in Windows. Currently, the device is able to pair with my Windows 10 laptop and I am able to read the incoming data off of it.
The same hardware is configured and working fine as a wireless MIDI device on Mac and iOS devices(which natively supports MIDI over Bluetooth). I am trying to get this feature implemented on Windows(which doesn't support MIDI over Bluetooth, although it was promised in Windows 10).
The device, when is paired, is showing up in the 'Bluetooth devices' section in device manager, I am trying to make this device showing up as a MIDI device in 'Sound, video and game controllers' section.
Any help/resources somebody can provide to help me crack this problem is highly appreciated.
Following is my current thought process to implement this.
Pair the device and read the data off of it. (Already implemented)
Create a virtual MIDI port. (Don't know how to implement this, I am currently checking out rtpMIDI)
Send the MIDI data which was read from the BLE device to the virtual MIDI port. (Still don't know how to implement this)
Any suggestions/comments on the above thought process as I am absolutely new to Windows Driver Development.
I am writing a controlling software for a generic USB HID device within a team, working on Windows 7. Due to my status as an intern, my possibilities are limited:
the software must work on Windows
the software must use the default HID driver Windows supplies
My problem is that however I try to access the device while using the HidUSB driver (according to Zadig) my interrupt transfer read attempts always result with a timeout while the device actually does send data. Writing to the device works all the time, whether I use HIDAPI, whether I use libusb, only reading fails. (this is a primitive device atm and even the final packet data specification isn't done, currently it just sends an ON or an OFF string towards the host, and writing to the device changes the state of a LED between 7 colors and off state, so that one's certainly working)
I can't think of the device being faulty, because if I replace the driver on Windows to the WinUSB driver with Zadig, it works with libusb (and hidapi can't open the device thereafter) and on Linux, just by reading /dev/hidraw also returns the data fine. I have also read the HID and the USB specifications and I know that the device descriptors state that the USB packetsizes are 8, while the HID input report's size is capped at 20, tho I don't know what report ID the device uses.
Checking the Windows communications with USBPcap and Wireshark, the sole difference I can notice among the handling of the device is the host packets asking for data is filled with 00s against the HidUSB driver compared to the CCs when used with the WinUSB driver.
For the record, I have already tried libusb, hidapi, HidLibrary and noone within the team has an idea what to do now.
I have also read that Windows disables access to HID keyboards and mice but I found no actual example of a device config ending up as an USB mice. The Device Manager lists my device twice under HID tho, once as HID-compliant device or how it calls (localized Win7 here) and once as USB Input Device, but doesn't list it among the Mouse or Keyboard option.
Sorted it out a while ago, but I think I'll write it down here if someone ends up with a similar issue in the future.
The Windows HID driver invalidates any incoming packet if the report's data size does not match the length of the sent data iow the size within the report descriptor. Linux and the device itself didn't cared that's why I also ruled that out as source during the time I brought the question here. In the above example the on/off message being 4-5 byte vs the reported 20 byte length was the problem, now that the device sends 20B messages, all the solutions which could write via HidUSB can read as well.
i'm currently developing a KMDF HID minidriver for the Nintendo Wii Remote. My
HID minidriver replaces the HidBth minidriver for the HIDClass driver (I'm using
the KMDF HID minidriver sample, where it is actually a filter driver and uses
this "kmdfhidminidriver" to forward all requests).
So my problem is, when i power off the Wii Remote (pressing the Power button or removing the batteries), the PnP-Manager won't
recognize the device is gone. Windows still shows the device in the device manager and thinks everything is fine and
running. The only hint, that the device is gone is, that the L2CAP-Channel is
closed and i get the L2CAP-Callback called with Indicator Code
"RemoteDisconnect".
My question is, how do i signal the PnP-Manager the device has disconnected? I
tried using "WdfDeviceSetDeviceState" with "Removed" set to true. But then the
Device Manager shows an driver error (Code 24). I would like to have a solution,
where the device gets removed from the Device Manager without any error, like
unplugging an USB device.
Additional information: i'm using WDK 8 and WDF 1.11; driver target systems are
Win 7 and 8.
Ok, i have to use "HidNotifyPresence". It is prototyped in "hidport.h", but unfortunately not documented yet.
It takes two arguments. The first one is a device object, which might be the FDO. The second one is a BOOLEAN. If true the device will be re-enumerated, else the device is suprise removed.
Since my driver is a filter driver, i need to provide my own PassThrough (shim) miniport driver, which will pass the FDO and "HidNotifyPresence" addresses to the filter driver.
I am wondering whether it is possible to display a message to the user when he connects a USB device. For example, I want to program the USB so that any PC that the device is connected to displays the pop-up window, saying Please leave the usb on this place.
It is NOT possible;
You wrote: " I want to program the usb so that any PC that the device is connected "
You'd rather program the PC not the USB
USB is a storage device only. Unfortunatelly you can't program all the PC's that USb might get into
The ONLY way this might be (yes it won't work in every case I guarantee) be tweaked is to have autorun.inf file in the USB pointing to a program on the USB that displays the message you want.
[Autorun]
Open=msg.exe
Due to most modern operating systems have tons of blocking mechanism to stop autorun programs this message has very slight chance to appear
You will need to first register for device notification. Then, you can implement a callback to detect when your USB device is inserted or removed. Within that callback you can do your messaging to the users based of your inspection of which device was inserted or removed.
This is only possible if the computer already has a driver installed for this device that implements this behavior. If, as I suspect, the device is actually a standard USB storage device, this is not possible.
I am developing a USB composite device. The composite device have 8 switches and one LED.
When I plugged the Composite device to PC,I could find five devices (each with same device ID but different instance IDs) in the HID section of Device Manager.
Why OS is showing multiple instances instead of One. Can anyone help me understand the concept?
As I recall 'composite device' is just a name in windows to mark that you have multiple devices on your USB line. There isn't a composite device class in the USB protocol. When you connect your USB device to your PC it communicates with all the devices contained in it and reports individually all their address and types. If you are missing some devices in your device manager it could be a driver issue or the device itself is broken. I don't know for sure but maybe there is a limit lower then it could be in theory in the windows hid host driver for the number of supported devices on a single line.