|
From: Xiaofan C. <xia...@gm...> - 2013-07-02 09:28:43
|
On Tue, Jul 2, 2013 at 5:03 PM, deepak_ <ig...@gm...> wrote: > Hi Xiaofan, > Thanks for your time and guidance. > Please find my answers inline: >> 1) What is IOCTL_xxxUSBCOMPOSITE_GET_VERSION? Is this >> an IOCTL for your filter driver? > > <<Deepak>> Yes, it is. To get the driver version. Okay. Take note you can not use either libusb-win32 or libusbx to issue the IOCTL to your filter driver. You can keep using your current codes which you copied from libusb-win32. >> 2) BTW, please take note libusb-win32 DLL codes (like windows.c) is >> under LGPL v2 license. So you will have to abide by the license. > > <<Deepak>> I'm sorry if I offended the license. I am not a lawyer. But probably the codes you copied are not that long so maybe you are okay. >> 3) If you use libusbx, then you should be able to get the serial >> number of the device without resorting to your filter driver >> at all. It is the same for libusb-win32, you should be able to >> use standard USB request to get the serial number. > > <<Deepak>> I would have already done it but the iSerialNumber member of the > dev_desc comes to be 0, so we cann't use it. I had tried it first. Actually, > the device has a serial number written in one of its objects (it follows a > Object Based Protocol). We have to read the serial number from there. In > order to get serial number, we have to write a request buffer to the HID > device which I am not sure how do i do it with libusbx. I am still looking > into it. I see. What do you mean by writing a request buffer to the HID device? Are you using a HID report? If it is using HID report, you can use libusbx. Are the Objects wrapped into HID reports (IN, OUT, Feature)? >> 4) Unless your own filter driver is doing something more special, >> I will suggest you to remove your own filter, then install >> libusb-win32 filter on top of the composite device, then >> migrate your application to use standard libusb-win32 API. > > <<Deepak>> We cann't remove the filter driver as it has some more > functionality added with it. Secondly, provided the good things in libusb > 1.0 (libusbx), we do not want to use libusb-win32 which uses libusb 0.1. > Also, we want to use a user-mode library (libusb-1.0 gives it). libusb-win32 is a user-mode library as well (the dll part, the kernel driver part is different). libusbx is purely a user-mode library. >> 5) After that, you can think about how to migrate your application >> to libusbx API. Please also take note that libusbx hotplug >> features have not been released for Windows even though >> older versions in Pete's repo may have some hotplug features >> but they are subjected to be changed. > > <<Deepak>> We want to use libusbx. So migration is probably what we don't > want. We expect hotplug feature to be implemented soon and therefore not > much migration would be needed when hotplugging will be supported in windows > as we would be already using libusbx. I see. If you are looking at hotplug, then HIDAPI is not a feasible solution right now. I agree it is better to use libusbx instead of libusb-win32 if you use HID since you do not need to use the libusb-win32 filter driver if you use libusbx. But I do not think you need to use WinUSB driver for your HID device since libusbx supports HID directly. If you have questions related to libusbx, take note it has its own mailing list. You should subscribe and ask libusbx related questions there. https://lists.sourceforge.net/lists/listinfo/libusbx-devel -- Xiaofan |