On 2012.07.17 01:46, Peter Stuge wrote: > So the Windows USB stack does not provide root hub descriptors?
Not at the moment, no. But if there's an USB 3.0 root hub driver out there that returns descriptors, and someone wants them, it shouldn't be too difficult to enable the feature. > The more I think about it the more I think that not exposing root > hubs at all would be a good thing. I disagree with that. There again, you want to add an arbitrary restriction that doesn't need to exist, on the false pretense that, because you cannot currently envision a case where someone should ever want to retrieve the root hub descriptors, it will never exist. We're a generic library => the less arbitrary restrictions we impose, the better, even more so as I already exposed a scenario (proprietary USB 3.0 root hub driver with descriptors) where listing the root hubs would be "a good thing". Linux also has the nice feature of using a root hub PID to give a hint about the USB speed (1d6b:0002 = USB 2.0, 1d6b:0003 = USB 3.0). That can come quite handy when a list of devices that include root hubs is easy to obtain. On a more general level, there's also the basic idea that if it has an USB port or plug, then it's an USB device that should be listed. For instance, say libusbx were to handle root hub <-> root hub connections (which as far as my understanding goes, isn't too far from USB 3.0 debug). With each root hub entity mirroring the other in terms of features, it doesn't really make sense to only list the other one while pretending homeside doesn't exist. Thus, as a libusbx maintainer, my vote will be to keep exposing root hubs (and if possible fix *BSD, so that it does). Now, of course, you're free to try to convince the other 3 libusbx maintainers to remove root hubs from the device list. > By the way, 255 has special meaning in Wireless USB, as do 128-254. > > WUSB uses 16-bit addresses over the air, that may be why Windows > uses unsigned short. That's good to know. I think the USB_NODE_CONNECTION_INFORMATION, that also uses USHORT is older than the formation of the WUSB group (Wikipedia says 2004), so I'm not too sure. On the other hand, when Microsoft wants an align, they usually add an unused attribute, so it seems they saw a possibility to go beyond 255. By the way, after USB_NODE_CONNECTION_INFORMATION and USB_NODE_CONNECTION_INFORMATION_EX, Windows 8 is about to introduce a USB_NODE_CONNECTION_INFORMATION_EX_V2 [1]. Shouldn't matter much to us though, since its only purpose (as _EX can already indicate if a device is operating at SuperSpeed) appears to be to tell if a device is SuperSpeed capable... Oh, and while I was looking at the new Windows 8 USB presents, there's a brand new USB_30_HUB_DESCRIPTOR structure [2]. Don't think that applies to root hubs though. I'll see if I can test, but it may take a while, as the Fresco Logic USB 3.0 controller I used on my Win8 test rig is both fried and not one that is natively supported by Windows 8 (still requires proprietary controller [3]). Also, some of the descriptor data from USB 3.0, such as wHubDelay, may be of interest to our users, so I think I'll probably allow the retrieval of hub descriptors in libusbx/Windows as I did for HID. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/windows/hardware/hh406295.aspx [2] http://msdn.microsoft.com/en-us/library/windows/hardware/hh406254.aspx [3] http://social.technet.microsoft.com/Forums/en/w8itprohardware/thread/ec623ec5-2ec8-4782-af1a-9b083b6113a3 ------------------------------------------------------------------------------ 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
