On Tue, Apr 9, 2013 at 5:54 AM, Pete Batard <p...@akeo.ie> wrote: > On 2013.04.08 19:12, Tim Roberts wrote: >> Xiaofan Chen wrote: >>> Somehow I got a strange warning under Windows 8 x64. The device >>> is a USB composite device (Amontec JTAGkey-2), both interface >>> use the WinUSB driver installed using Zadig. Not so sure if this >>> has something to do with the fact this is a virtual machine (using >>> VirtualBox under Mac OS X). >> >> I'm a little confused here. Do you have one driver matching the >> composite device, or do you have two drivers, one for each interface? > > I guess that's 2 drivers, as one needs to use the advanced options of > Zadig to replace the driver for the usbcgpp device otherwise.
Yes that is right. >> When you have one driver per interface, >> the composite driver rewrites the descriptors so that each function >> driver sees a single interface device. > > Yes, but the issue is that libusb was written with a Linux frameset in > mind, where composite devices are not seen as 2 independent entities but > as a single one. So we have to compensate for that in the Windows > backend, to provide for a cross platform implementation that does its > best at behaving the same across the board. I do not think this interpretation is totally correct under Linux. > Otherwise, the expectation that when you open a libusb(x) composite > device, you are entitled exclusive access all its interfaces will not > hold true on Windows as it is for other platforms. Again, I think that is wrong understanding. You need to claim an interface of a USB composite device to gain exclusive access to the interface, under Linux or Mac OS X. > And that's the reason why, independently of xusb, the Windows backend > will also claim all interfaces of a composite device on open [2]. > Sure would be nice if we could just address each interface > independently, but we're just constrained by how libusb(x) is meant to > work on other platforms. I believe the reason may be because of the limitation of WinUSB you mentioned is this old discussion thread. http://libusb.6.n5.nabble.com/Can-t-Send-Control-Messages-to-usb-device-in-Windows-td7150i100.html#a7193 ++++++++ >> you need to claim interface 0 with WinUSB if you want to access >> other interfaces, > > Can you expand on this? > > Do you know why this seemingly odd restriction is there? You'd be amazed at the amount of restrictions Microsoft's API have compared to their Linux counterparts The answer is simple. You need a Windows handle for each WinUSB interface, and rather than do something generic like using an API call that takes an interface number and returns a handle, WinUsb_Initialize must be used to return the handle of the first interface whereas WinUsb_GetAssociatedInterface, which must get as a parameter the handle returned by WinUsb_Initialize as well as an interface number, returns the handle for other interfaces. Therefore, there's no accessing WinUSB interface #1 or later if you don't have access to interface #0. I kind of remember trying temporarily getting a handle to interface 0 to discard it right after that, but that was some time ago (plus you'd then need to handle multithread issues). ++++++++++ > With this being said, I ran a test on Windows 8 against an FTDI based > composite device (Olimex JTAG), and did not see the issue reported by > Xiaofan. Yes this is the first time I saw such a problem, under real or virtual machine. That is why I feel a bit strange. > Hard to say what virtualization will do behind the scenes, so unless > we get similar reports on actual hardware, I'm not sure I want to > investigate that issue much. I agree. I will check if I can reproduce such an issue with other machines. -- Xiaofan ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
