From: Xiaofan C. <xia...@gm...> - 2015-03-04 00:08:44
|
On Tue, Mar 3, 2015 at 1:59 AM, Dmitry Fleytman <dm...@da...> wrote: > Some distinctive UsbDk properties are: > > 1. UsbDk supports all types of devices and interfaces - bulk, isochronous, > composite, HID etc. > 2. Device capture process is totally dynamic, i.e. no inf files and > self-signing needed, any device can be captured. > 3. UsbDk co-exists with original device driver, when the device is not > captured original driver is loaded by the system automatically. > 4. If user mode client terminates unexpectedly for any reason system reverts > to original device driver immediately. > 5. Being USB filter driver UsbDk doesn't require WHQL-ing > as per Microsoft requirements. >From the above, it seems to me that when the device is captured, the original device driver is not loaded. So it is not really "co-exists", right? It seems to me it is more a type of dynamic switching of driver. Am I right? http://cgit.freedesktop.org/spice/win32/usbdk/tree/ARCHITECTURE "UsbDk.sys is both USB filter driver and generic USB device driver. On installation it is being registered as USB filter driver and system invokes it for each new USB device being discovered including USB hubs. On invocation UsbDk.sys checks type of underlying device and creates filter instances for USB hubs only. Being a filter of USB hub UsbDk.sys receives all requests from upper part of USB stack including enumeration requests that originated by PNP manager (IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS)." The filter mentioned above means actually UsbDk acts as a upper filter driver of USB Root Hub, not really a upper filter driver of the USB device (which libusb-win32 filter driver is). "Upon enumeration request completion by USB hub driver UsbDk.sys scans array of child devices returned and in case there are devices to be redirected (according to current configuration) it attaches as filter to those devices as well. As a result all PNP manager requests pass via UsbDk.sys callbacks and the latter patches device ID properties as needed to make PNP manager recognize the device as a generic USB device. Besides that UsbDk.sys marks underlying device object as raw PDO so the system assigns the driver who created it (UsbDk.sys) to be the device driver as well." So it seems that UsbDk only acts as a upper filter driver for the device to be captured briefly and then forces re-enumeration of the device and then act as a device driver. Am I right? In that case, it seems UsbDk is really useful under Windows to implement dynamically attach/detach the UsbDk driver (similar to Linux where the original driver can be attached/detached, detached means to use usbfs driver). > > Dmitry Fleytman (3): > windows: Move common definitions to a separate file > usbdk: Introduce usbdk backend > build: Integrate usbdk backend > > configure.ac | 9 + > libusb/Makefile.am | 14 +- > libusb/core.c | 6 + > libusb/libusbi.h | 1 + > libusb/os/UsbDk/UsbDkData.h | 100 +++++ > libusb/os/UsbDk/UsbDkHelper.h | 239 ++++++++++++ > libusb/os/windows_nt_common.c | 572 +++++++++++++++++++++++++++ > libusb/os/windows_nt_common.h | 67 ++++ > libusb/os/windows_usb.c | 556 ++------------------------ > libusb/os/windows_usb.h | 14 +- > libusb/os/windows_usbdk.c | 890 ++++++++++++++++++++++++++++++++++++++++++ > libusb/os/windows_usbdk.h | 24 ++ > 12 files changed, 1944 insertions(+), 548 deletions(-) > create mode 100644 libusb/os/UsbDk/UsbDkData.h > create mode 100644 libusb/os/UsbDk/UsbDkHelper.h > create mode 100644 libusb/os/windows_nt_common.c > create mode 100644 libusb/os/windows_nt_common.h > create mode 100755 libusb/os/windows_usbdk.c > create mode 100644 libusb/os/windows_usbdk.h Just wondering if the files can be compiled by MSVC. It would be good to provide VS solutions files (say VS2013) and WDK 7 build files. Take note libusb Windows backend supports MSVC along with MinGW.org, MinGW-w64 and Cygwin. -- Xiaofan |