Markus wrote: > I can't see a generally reliable way to get my hands on the HC > information while at the same time, being able to infer which > devices are connected (by means of libusb_get_bus_number() result). > Do I overlook something here?
Well the HC is not a USB device, so it does not fit into the libusb-1.0 API device model, which is (only) for USB devices. > Right now, I can reliably tell which devices share a common bus. > However, currently it's only Windows that returns the correct > VID/PID for the root hub. Again, the root hub is not a USB device, but an implementation-specific part of the host controller. The root hub thus doesn't have USB VID/PID. If the HC is on a PCI bus then it will have a PCI VID/PID, but pretending that those are USB ids is a bad idea, since they are two unrelated namespaces. Consider a PCMCIA (not CardBus) USB host controller. There you would only have PCMCIA ids to go on. Another unrelated namespace. Bad idea to mix with USB ids. > So it looks as if there is no possible way to tell which host > controller model runs a given bus except for Windows. Why do you want to do this again? You mentioned bus bandwidth. How would you like to use the bandwidth knowledge? > Do you see a chance to get such a matching done in libusbx or do > you consider that outside its scope? I think that HCs and root hubs should not be exposed as USB devices, because they are not USB devices. That doesn't mean that the API must never be extended to deal also with those devices, or perhaps more likely the USB busses that they implement, but I currently don't see the use-case so it's difficult to suggest any API design. It helps to know more about how you want to use the bus knowledge? Thanks //Peter ------------------------------------------------------------------------------ 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 libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
