On 2014.01.23 19:43, Bent Bisballe Nyeng wrote: > On 01/23/14 20:13, Tim Roberts wrote: >> Bent Bisballe Nyeng wrote: >>> We have a composite device that works like a USB HUB connecting to one >>> device at a time. >>> When a new connection is made the endpoints change although the device >>> connection itself is not changed. >> >> What led you to think that was a legitimate thing to do? Once a driver >> has done a "set configuration", it's not clear that the endpoint >> configuration is allowed to change. You can certainly have multiple >> alternate settings, where each setting has a different set of endpoints, >> but I don't see how you can possibly expect an on-the-fly change to >> work. How would you notify the host that things have changed? You >> can't expect it to poll your descriptors repeatedly. > > Allow me to elaborate a bit; we did not /make/ the device, we are merely > /using/ it and need it to work. I do not know whether the behavior is > embraced by the USB specification, all I'm saying is, that it did work > with libusb once, and the patch made it work again
I'm with Tim on this, and I will even go further than that. Anything that is not explicitly specified in the USB specs is left to the implementer's choice, and the general libusb direction is to probe and update a device's parameters as little as we possibly can. You say your device "works like a HUB". Does it trigger a device removal & insertion notification from the OS when a new connection is made? If not, then I have to ask what you are planning to do once libusb follows through with what we ultimately want to do with regards to hoptplug, which would be to only update our internal USB device tree on device insertion/removal. Unless your device acts as if a removal took place when it switches connection then, you'll probably find that even if we were to revert this section, a future version of libusb would likely break that behaviour again... The only reason it used to work is that the current Windows implementation has no hotplug awareness, so we enumerate the whole USB tree, including the device's property, every time a device is opened. Of course, this is less than optimal, so when we have means to make that process slightly faster (with the code you want to see removed for instance), we will add it, until, eventually, we might be able to enumerate the whole bus once per session, and only update our tree on a single device basis, as they are removed or inserted. Overall, you may have been lucky, and got to use a version of libusb that unintentionally happened to provide the "feature" you wanted to rely on. But we can make no promise of backwards compatibility on such accidental "features", especially as our plan is to go in the opposite direction. Thus I don't think we want to revert this code. Instead, I would advise to try to factor out "luck" or reliance on a behaviour that the USB specifications leave unclear, even as it may require a greater effort from your side. Oh, and I'm also curious as to how your device is meant to behave on other OSes, such as Linux or OS X, especially when using the latest libusb. Do you see the endpoint update there? Regards, /Pete PS: I'm currently planning to delay the 1.0.18 release for a couple more days (current estimate = Saturday or Sunday), as we're still waiting on Nathan's feedback and I could use the time on a couple non libusb things. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
