|
From: Paul Q. <pa...@wo...> - 2018-04-27 08:17:09
|
Hi. I've been trying to get dfu-util to work properly on Windows. After submitting a patch to fix the control transfer interface selection ( https://github.com/libusb/libusb/pull/398) it can now write firmware in DFU mode. Unfortunately, it still can't work with runtime mode because libusb does not support composite devices on Windows. The only fix at the moment is to replace the composite parent driver with Zadig, but this is unsatisfactory as it means composite devices can't "just work" on Windows. Pete Batard provides great insight into this issue here: https://sourceforge.net/p/libusb/mailman/message/33176212/ The short version is that Windows treats composite devices as multiple different devices from a driver point of view, where as Linux treats them as one device. As a result, libusb is unable to open the parent device as it does not have a supported driver. I now have to choose between writing a new, Windows only DFU tool or fixing libusb. So I thought fixing libusb would be the better option. When researching this issue it seems to be affecting a lot of people. What is the best way to sort this out once and for all? Is adding support for the Windows composite driver likely to work? Unfortunately, as Pete Batard notes, the Windows back-end is a bit of a jungle because it tries to fit the libusb model. The goal would be to allow libusb to seamlessly open any interface on the composite device, automatically selecting the correct child device. What other options exist? To be clear I'm willing to do the work here, I'm just looking for some discussion of the best way to implement this. Regards, Paul |