Menu
▾
▴
Re: [libusb] Windows composite device fix
|
From: Paul Q. <pa...@wo...> - 2018-04-30 17:34:27
|
Hi Philip. Yes, all that is correct. The crucial bit that libusb can't support is that the DFU runtime descriptor requires its own interface, which makes the device a composite device (interfaces separate out functions) that the WinUSB backend doesn't support. The examples in the DFU spec demonstrate this, if you are interested. These are the options I can think of. 1. Fix libusb. Seems to be very difficult, if not impossible due to architectural issues. At the very least, a substantial amount of work. 2. Write a new dfu-util that uses a different library, such as libusbp. 3. Write a new bootloader system from scratch. I can't decide between 2 and 3. DFU is awkward and limited, which is why multiple manufacturers released their own custom extensions. But it is the standard... Regards, Paul Qureshi On Mon, 30 Apr 2018 at 18:08, <Phi...@mi...> wrote: > When a device is in run-time mode (in that, in its normal mode of operation), and fully supports DFU, then it will contain two additional USB descriptors in addition to its normal set of USB descriptors. The configuration descriptor of the device will indicate one additional interface descriptor. That interface descriptor is the run-time DFU interface descriptor. The second descriptor that follows the DFU interface descriptor is the run-time DFU functional descriptor. Both of these are explained in the DFU spec. > And yes, a DFU capable device will respond to DFU_DETACH on its EP0 when in run-time mode (to allow the host to bump it, int that re-enumerate it, into DFU-mode. > If the device can be bumped into DFU mode, but does not have the additional DFU run-time descriptors as part of its configuration, then you have to gimmick something up and play games like relying on a list of run-time PIDs that you know support going into DFU mode. > ________________________________________ > From: Paul Qureshi [pa...@wo...] > Sent: Monday, April 30, 2018 9:53 AM > To: lib...@li... > Subject: Re: [libusb] Windows composite device fix > Okay, I have tried the simple fix of making the DFU interface zero instead > of one, but it didn't help. Libusb still gives the same unsupported error. > One other option I thought of is to support DFU on interface 0 without the > descriptor. You can't have a DFU descriptor on interface 0 while it is also > being used for something else like HID, but you can respond to DFU setup > packets anyway. The down side is that there is no way to detect a DFU > capable device if it lacks the descriptors, but at least it will work on > Windows. Some kind of override flag will need to be added to dfu-util. > Regards, > Paul > On Sat, 28 Apr 2018 at 18:54, Paul Qureshi <pa...@wo...> wrote: > > Hi David. > > Thank you for this. I shall try it on Monday. > > You are right, I am using DFU so that I can take advantage of dfu-util and > > other software that supports it. But given the situation, where I will > > either have to do a massive amount of work to fix libusb or re-write > > dfu--util anyway, maybe creating a new bootloader system is the way to go. > > DFU is kinda rubbish anyway... Very limited in what it can do, resulting > in > > incompatible extensions by several manufacturers. > > The down-side is that libusb is the most popular option, and this > > limitation prevents a lot of otherwise great software like dfu-tool from > > working on the most popular OS. I guess you have to pick your battles > > though, and from the sounds of it fixing libusb won't be easy. > > In any case, I will try your library. > > Regards, > > Paul > > On Sat, 28 Apr 2018 at 18:21, David Grayson <dav...@gm...> > wrote: > > > Hello Paul Qureshi and others, > > > I made a new library named libusbp[1] which was developed with > > > Windows, Linux, and macOS in mind, and it has a different model for > > > connecting to devices that works OK on all of them, at least for my > > > limited uses: > > > 1) You call libusbp_list_connected_devices to get a list of physical > > > USB devices with a vendor ID, product ID, revision number, and serial > > > number. > > > 2) You use libusbp_generic_interface_create to create an object > > > representing a USB interface with a generic driver (like WinUSB). > > > This function takes a USB device, an interface number, and a boolean > > > saying whether the device is composite. > > > 3) You use libusbp_generic_handle_open to open a handle to the generic > > > interface object so you can actually do I/O. > > > So for my limited use cases, which basically consist of connecting to > > > an interface and sending some control transfers, I don't have to do > > > any platform specific code outside of the library. > > > By the way, it seems like the main point of using DFU is so your > > > device can be compatible with some existing software, but if that > > > software doesn't fit your needs and must be modified, you might > > > consider making a custom bootloader with custom software tailored for > > > your needs. > > > --David > > > [1]: https://github.com/pololu/libusbp > > > On Fri, Apr 27, 2018 at 1:16 AM, Paul Qureshi <pa...@wo...> wrote: > > > > 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 > > > > > > > > ------------------------------------------------------------------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > > > > libusb-devel mailing list > > > > lib...@li... > > > > https://lists.sourceforge.net/lists/listinfo/libusb-devel ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > libusb-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |
