Hi Rich, On 2012.06.28 15:00, Xiaofan Chen wrote: > On Tue, Jun 26, 2012 at 4:52 AM, Rich von Lehe <[email protected]> wrote: >> In lieu of set_configuration in this case (there is only one config), >> one process would claim_interface 0 and the other process would >> claim_interface 1. I have a suspicion that the underlying >> implementation in Libusb is locking the device with the first call to >> claim_interface, since I get permission errors when making that call >> from the 2nd process. I saw an email on this list saying as much for >> the OpenBSD implementation, though I'm on Windows/WinUSB. >> >> Is it best to go to the Libusb code and see if I can figure if that's >> really the case? >> > > If you use Windows, you probably want to use libusbx. > http://libusbx.org/ > > On the other hand, WinUSB has several limitation and the above > may be one of the limitations. > http://sourceforge.net/apps/mediawiki/libusbx/index.php?title=Windows
Indeed, there are basically 2 issues that need to be addressed when using WinUSB for a libusb/libusbx implementation: 1. The only way to access an interface from WinUSB is to have access to the first one (some of the design decisions for WinUSB are very disputable - we have to work with them). 2. Because this is how devices can behave on Linux/Mac, libusb expected control transfers to be possible before any interface is claimed. However WinUSB does not make that possible - instead we must always claim an interface to be able to issue control transfers, as a per the above, this requires some access to the first one. Then there's also the issue of WinUSB not supporting "multiple concurrent applications" as per http://msdn.microsoft.com/en-us/library/windows/hardware/ff540215.aspx. Of course this will creates some issue for applications/processes that try to access interfaces independently, such as yours. Even if libusb/libusbx allowed some finer grained interface claiming (we used to provide a compilation option disable autoclaiming of interfaces for control requests), you're probably in for a lot of trouble if you want to design 2 processes accessing 2 interfaces on Windows when relying on WinUSB. And considering that you're not going to gain much in terms of throughput by splitting access, with everything concurrently ending up on the same bus, I'm not sure there's much advantage to use separate processes for interface access. The device may show up as two devices in the device manager, but unfortunately, Microsoft does not appear to have been consistent with that approach when they devised WinUSB, as it has very little provision, if any, to allow independent interface access... > The next version of libusbx will integrate the support of libusb0.sys > and libusbk.sys which may lift the limitations. At this stage, even with the planned early libusb0/libusbK support, it is unlikely that the next version of libusbx will provide independent interface access, as this requires additional work from what we plan to provide at first. As with any new feature (and limited resources!), gradual implementation works best, so the above is unlikely to be implemented on the first release. Maybe the next one... Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libusbx-devel
