From: Dave C. <dav...@gm...> - 2011-06-08 01:08:44
|
Hello Pete, Peter, Xiaofan et al... I'm running into an issue during device listing on some win 7 machines. In particular, when I retrieve the device list, it does not return a list with the devices I expect to see (using the latest master from libusb-pbatard branch, as well as PBR336, both with the same behavior). After turning on debug logging in the library and re-running, I see warnings on the device VID/PID's that I care about (VID 224F) relating to them being detected in a late pass and being ignored. I presume this is in part, why they are not being returned on the device list. This particular code has been run and tested on many different windows machines and has worked predictably and reliably in the past. The machine it's running on is a new win7/64 machine. The hardware has been plugged into the machine for a reasonable period of time. Unplugging and re-plugging hardware doesn't seem to affect it. Device manager looks good, all devices configured and installed properly... I'm kind of at a loss for how to interpret this or what to do about... Thoughts? Thanks, -Dave libusb:debug [libusb_init] created default context libusb:debug [libusb_init] libusb:debug [init_polling] Will use CancelIoEx for I/O cancellation libusb:debug [htab_create] using 1021 entries hash table libusb:debug [usbi_add_pollfd] add fd 3 events 1 libusb:debug [libusb_get_device_list] libusb:debug [windows_clock_gettime_threaded] hires timer available (Frequency: 1948125 Hz) libusb:debug [windows_get_device_list] allocating new device for session [C3] libusb:debug [windows_get_device_list] allocating new device for session [2E5] libusb:debug [windows_get_device_list] allocating new device for session [2FE] libusb:debug [get_api_type] driver(s): NUSB3HUB libusb:debug [windows_get_device_list] allocating new device for session [3EB] libusb:debug [get_api_type] driver(s): USBHUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [1CE] libusb:debug [get_api_type] driver(s): USBHUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [19D] libusb:debug [get_api_type] driver(s): NUSB3HUB libusb:debug [windows_get_device_list] allocating new device for session [1F0] libusb:debug [get_api_type] driver(s): NUSB3HUB libusb:debug [windows_get_device_list] allocating new device for session [BA] libusb:debug [get_api_type] driver(s): NUSB3HUB libusb:debug [windows_get_device_list] allocating new device for session [BB] libusb:debug [get_api_type] driver(s): NUSB3HUB libusb:debug [windows_get_device_list] allocating new device for session [236] libusb:debug [get_api_type] driver(s): USBHUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [3E4] libusb:debug [get_api_type] driver(s): USBHUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [83] libusb:debug [windows_get_device_list] found existing device for session [1CE] (0.0) libusb:debug [init_device] (bus: 2, addr: 255, depth: 0, port: 0): '\\.\USB#ROOT_HUB20#4&1117A8E6&0' libusb:debug [windows_get_device_list] found existing device for session [19D] (0.0) libusb:debug [init_device] (bus: 3, addr: 255, depth: 0, port: 0): '\\.\USB#ROOT_HUB20#4&248A91D5&0' libusb:debug [windows_get_device_list] allocating new device for session [4B] libusb:debug [init_device] got bus number from ancestor #2 libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 39 bytes) libusb:debug [init_device] (bus: 3, addr: 2, depth: 1, port: 3): '\\.\USB#VID_147E&PID_2016#6&3AF1EAA2&0&3' libusb:debug [windows_get_device_list] allocating new device for session [2F3] libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 722 bytes) libusb:debug [init_device] (bus: 3, addr: 3, depth: 1, port: 6): '\\.\USB#VID_17EF&PID_480F#6&3AF1EAA2&0&6' libusb:debug [windows_get_device_list] extra GUID: {FF440353-416E-4E94-8C66-74F173A81039} libusb:debug [windows_get_device_list] extra GUID: {C7A69D58-8594-11DF-B991-98FADFD72085} libusb:debug [windows_get_device_list] extra GUID: {C7A69D58-8594-11DF-B991-98FADFD72085} libusb:debug [windows_get_device_list] extra GUID: {C7A69D58-8594-11DF-B991-98FADFD72085} libusb:debug [windows_get_device_list] extra GUID: {C7A69D58-8594-11DF-B991-98FADFD72085} libusb:debug [windows_get_device_list] allocating new device for session [3BD] libusb:debug [init_device] got bus number from ancestor #2 libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 46 bytes) libusb:debug [init_device] (bus: 2, addr: 2, depth: 1, port: 3): '\\.\USB#VID_8086&PID_0187#6&19D2BC7A&0&3' libusb:debug [windows_get_device_list] found existing device for session [3E4] (3.0) libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 25 bytes) libusb:debug [init_device] (bus: 3, addr: 1, depth: 1, port: 1): '\\.\USB#VID_8087&PID_0020#5&3C7F0E4&0&1' libusb:debug [windows_get_device_list] found existing device for session [83] (2.0) libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 25 bytes) libusb:debug [init_device] (bus: 2, addr: 1, depth: 1, port: 1): '\\.\USB#VID_8087&PID_0020#5&CF3B5E&0&1' libusb:debug [get_api_type] driver(s): USBSTOR libusb:warning [windows_get_device_list] '\\.\USB#VID_058F&PID_6366#058F0O1111B1' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): USBSTOR libusb:warning [windows_get_device_list] '\\.\USB#VID_058F&PID_6366#8&469AC09&0&4' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): USBSTOR libusb:warning [windows_get_device_list] '\\.\USB#VID_058F&PID_6366#8&E50049C&0&4' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): USBSTOR libusb:warning [windows_get_device_list] '\\.\USB#VID_058F&PID_6366#9&2DBB2DF6&0&4' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): WUDFRD libusb:debug [get_api_type] lower filter driver(s): WINUSB libusb:debug [get_api_type] matched lower filter driver name against WinUSB API libusb:debug [windows_get_device_list] found existing device for session [4B] (3.2) libusb:debug [get_api_type] driver(s): USBCCGP libusb:debug [get_api_type] matched driver name against Composite API libusb:debug [windows_get_device_list] found existing device for session [2F3] (3.3) libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:warning [windows_get_device_list] '\\.\USB#VID_224F&PID_0001#6&12E571E8&0&4' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:warning [windows_get_device_list] '\\.\USB#VID_224F&PID_0002#7&144DE110&0&3' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:warning [windows_get_device_list] '\\.\USB#VID_224F&PID_0002#8&469AC09&0&3' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:warning [windows_get_device_list] '\\.\USB#VID_224F&PID_0002#8&E50049C&0&3' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:warning [windows_get_device_list] '\\.\USB#VID_224F&PID_0002#9&2DBB2DF6&0&3' was only detected in late pass (newly connected device?) - ignoring libusb:debug [get_api_type] driver(s): BPUSB libusb:debug [windows_get_device_list] found existing device for session [3BD] (2.2) libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [libusb_unref_device] destroy device 1.0 libusb:debug [libusb_unref_device] destroy device 2.0 libusb:debug [libusb_unref_device] destroy device 3.0 libusb:debug [libusb_unref_device] destroy device 0.0 libusb:debug [libusb_unref_device] destroy device 0.0 libusb:debug [libusb_unref_device] destroy device 0.0 libusb:debug [libusb_unref_device] destroy device 0.0 libusb:debug [libusb_unref_device] destroy device 0.0 libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_unref_device] destroy device 2.255 libusb:debug [libusb_unref_device] destroy device 3.255 libusb:debug [libusb_unref_device] destroy device 3.2 libusb:debug [libusb_unref_device] destroy device 3.3 libusb:debug [libusb_unref_device] destroy device 2.2 libusb:debug [libusb_unref_device] destroy device 3.1 libusb:debug [libusb_unref_device] destroy device 2.1 |
From: Xiaofan C. <xia...@gm...> - 2011-06-08 02:02:09
|
On Wed, Jun 8, 2011 at 9:08 AM, Dave Camarillo <dav...@gm...> wrote: > Hello Pete, Peter, Xiaofan et al... I'm running into an issue during > device listing on some win 7 machines. In particular, when I retrieve > the device list, it does not return a list with the devices I expect > to see (using the latest master from libusb-pbatard branch, as well as > PBR336, both with the same behavior). > > After turning on debug logging in the library and re-running, I see > warnings on the device VID/PID's that I care about (VID 224F) relating > to them being detected in a late pass and being ignored. I presume > this is in part, why they are not being returned on the device list. > This particular code has been run and tested on many different windows > machines and has worked predictably and reliably in the past. The > machine it's running on is a new win7/64 machine. > > The hardware has been plugged into the machine for a reasonable period > of time. Unplugging and re-plugging hardware doesn't seem to affect > it. Device manager looks good, all devices configured and installed > properly... > > I'm kind of at a loss for how to interpret this or what to do about... > > Thoughts? I think it will be good to tell us more about the device and post the "lsusb -vvv" (Linux) or usbview (Windows, http://www.ftdichip.com/Support/Utilities.htm ) result for this device. I am thinking this device can be the problem -- it may have some issues with WinUSB driver under the Win 7 x64 machine. The other possibility is that the new enumeration codes have some problems with your device. In that case, you can try the older versions of libusb-pbatard, say pbr310 which predates the new enumeration. http://code.google.com/p/libusb-winusb-wip/downloads/list libusb_2010.10.06.7z -- Xiaofan |
From: Xiaofan C. <xia...@gm...> - 2011-06-08 02:05:58
|
On Wed, Jun 8, 2011 at 9:08 AM, Dave Camarillo <dav...@gm...> wrote: > libusb:debug [get_api_type] driver(s): NUSB3HUB > Another guess here, does this machine uses USB 3.0? If yes, what is the chip used? Try to put your device to a different port (USB 2.0) only and see if that helps. Normally machines will have only a few USB 3.0 ports and the rest will be USB 2.0 ports. There are multiple reports that vendor' USB 3.0 driver is causing problems with some USB device. Microsoft does not provide USB 3.0 driver as of now. -- Xiaofan |
From: Tim R. <ti...@pr...> - 2011-06-08 16:46:41
|
Xiaofan Chen wrote: > > Another guess here, does this machine uses USB 3.0? If yes, > what is the chip used? I can answer that for him. Yes, it does, and it's an NEC controller. I recognize the name "nusb3hub". > There are multiple reports that vendor' USB 3.0 driver > is causing problems with some USB device. Microsoft > does not provide USB 3.0 driver as of now. Exactly right. I cringed when I saw "nusb3hub" in his stack. I wrote a streaming driver for a web camera based on the Cypress FX2 about 4 years ago. Besides my own extensive testing, it's been running happily for many thousands of customers since that time, in both 32-bit and 64-bit. This week, I suddenly have a report from a potential customer who has tried the camera in 9 different computers and had troubles in all of them. In every case, the failure occurs only in a 64-bit system, and only in a USB 3 port or a eSATA/USB2 combo port. USB 3 in Windows right now is a complete crap shoot, and will remain that way until Microsoft releases support in Windows 8. At least, we assume there will be support in Windows 8 -- nothing has been announced. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Pete B. <pb...@gm...> - 2011-06-08 10:13:52
|
Hi Dave, > libusb:debug [windows_get_device_list] allocating new device for session [2FE] > libusb:debug [get_api_type] driver(s): NUSB3HUB > libusb:debug [windows_get_device_list] allocating new device for session [3EB] > libusb:debug [get_api_type] driver(s): USBHUB > libusb:debug [get_api_type] matched driver name against HUB API From the information above, I think the problem is that the current backend does not handle USB 3.0 hubs, as I wasn't aware Microsoft had changed their hub driver service name from "USBHUB" to "NUSB3HUB" until now. As you can see above, for 3.0 hubs, we're missing a line "matched driver name against HUB API", that's supposed to occur right after we've picked up the driver name. Looks to me like the late detection messages is a direct result of libusb not having identified the parent hubs for these devices. Hopefully the simple fix I just pushed, will avoid that (untested, as I don't have access to anything 3.0 ATM). The fix is only in the git branch for now, so you will have to issue a git pull and recompile from source. If you confirm that this solves your problem, I'll produce a binary release. Regards, /Pete |
From: Xiaofan C. <xia...@gm...> - 2011-06-08 10:30:16
|
On Wed, Jun 8, 2011 at 6:14 PM, Pete Batard <pb...@gm...> wrote: > Hi Dave, > >> libusb:debug [windows_get_device_list] allocating new device for session [2FE] >> libusb:debug [get_api_type] driver(s): NUSB3HUB >> libusb:debug [windows_get_device_list] allocating new device for session [3EB] >> libusb:debug [get_api_type] driver(s): USBHUB >> libusb:debug [get_api_type] matched driver name against HUB API > > From the information above, I think the problem is that the current > backend does not handle USB 3.0 hubs, as I wasn't aware Microsoft had > changed their hub driver service name from "USBHUB" to "NUSB3HUB" until now. No it is not Microsoft's driver. Microsoft does not support USB 3.0 yet so the driver is from the USB 3.0 host controller vendors, in this case, it is from Renesas (was NEC, now part of the combined Renesas). > As you can see above, for 3.0 hubs, we're missing a line "matched driver > name against HUB API", that's supposed to occur right after we've picked > up the driver name. Looks to me like the late detection messages is a > direct result of libusb not having identified the parent hubs for these > devices. > > Hopefully the simple fix I just pushed, will avoid that (untested, as I > don't have access to anything 3.0 ATM). The fix is only in the git > branch for now, so you will have to issue a git pull and recompile from > source. If you confirm that this solves your problem, I'll produce a > binary release. > -- Xiaofan |
From: Pete B. <pb...@gm...> - 2011-06-08 14:39:51
|
On 2011.06.08 11:30, Xiaofan Chen wrote: > No it is not Microsoft's driver. Microsoft does not support USB 3.0 > yet so the driver is from the USB 3.0 host controller vendors, in > this case, it is from Renesas (was NEC, now part of the combined > Renesas). Thanks for the info. I guess we might have the same issue for other host controller vendors, but it looks to me like everybody is using NEC/Renesas (or compatible) at the moment. Do you know of other chipset manufacturers providing their own drivers? Regards, /Pete |
From: Tim R. <ti...@pr...> - 2011-06-08 16:50:07
|
Pete Batard wrote: >> libusb:debug [windows_get_device_list] allocating new device for session [2FE] >> libusb:debug [get_api_type] driver(s): NUSB3HUB >> libusb:debug [windows_get_device_list] allocating new device for session [3EB] >> libusb:debug [get_api_type] driver(s): USBHUB >> libusb:debug [get_api_type] matched driver name against HUB API > From the information above, I think the problem is that the current > backend does not handle USB 3.0 hubs, as I wasn't aware Microsoft had > changed their hub driver service name from "USBHUB" to "NUSB3HUB" until now. They have not done so. NUSB3HUB.SYS is a USB 3.0 hub driver written by NEC, not by Microsoft. There is no USB 3.0 support from Microsoft as of yet. If you're running USB 3 on Windows, you are running a host controller driver and hub drivers written by the manufacturer. No one has any idea whether these manufacturer-specific drivers are following Microsoft's rules, or rules of their own, and there is no documentation. USB 3.0 on Windows must be considered experimental at this point. It's the wild, wild west. It's not clear that it is beneficial to make any major changes based on the USB 3 code in the wild. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Dave C. <dav...@gm...> - 2011-06-09 00:17:49
|
Thanks for all the feedback guys, very much appreciated. I did try re-compiling with Petes latest changes, and I would describe the problem as "less bad", but still not working (output below)... We ended up putting all the hardware onto USB 2.0 ports on the machine and things worked perfectly after that... BTW, this happened to be on a new Lenovo Thinkpad w510 with win7/64. It does raise some good questions regarding what functionality should or should not be supported... For the current version, I suspect that answer should be 'no'... Thanks, -Dave libusb:debug [libusb_init] created default context libusb:debug [libusb_init] libusb:debug [init_polling] Will use CancelIoEx for I/O cancellation libusb:debug [htab_create] using 1021 entries hash table libusb:debug [windows_clock_gettime_threaded] hires timer available (Frequency: 1948222 Hz) libusb:debug [usbi_add_pollfd] add fd 3 events 1 libusb:debug [libusb_get_device_list] libusb:debug [windows_get_device_list] allocating new device for session [C3] libusb:debug [windows_get_device_list] allocating new device for session [2E5] libusb:debug [windows_get_device_list] allocating new device for session [2FE] libusb:debug [get_api_type] driver(s): NUSB3HUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [3EB] libusb:debug [get_api_type] driver(s): USBHUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [1CE] libusb:debug [get_api_type] driver(s): USBHUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [19D] libusb:debug [get_api_type] driver(s): USBHUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [3E4] libusb:debug [get_api_type] driver(s): USBHUB libusb:debug [get_api_type] matched driver name against HUB API libusb:debug [windows_get_device_list] allocating new device for session [83] libusb:debug [windows_get_device_list] found existing device for session [1CE] (0.0) libusb:debug [init_device] (bus: 2, addr: 255, depth: 0, port: 0): '\\.\USB#ROOT_HUB20#4&1117A8E6&0' libusb:debug [windows_get_device_list] found existing device for session [19D] (0.0) libusb:debug [init_device] (bus: 3, addr: 255, depth: 0, port: 0): '\\.\USB#ROOT_HUB20#4&248A91D5&0' libusb:debug [windows_get_device_list] allocating new device for session [4B] libusb:debug [init_device] got bus number from ancestor #2 libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 39 bytes) libusb:debug [init_device] (bus: 3, addr: 3, depth: 1, port: 3): '\\.\USB#VID_147E&PID_2016#6&3AF1EAA2&0&3' libusb:debug [windows_get_device_list] allocating new device for session [2F3] libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 722 bytes) libusb:debug [init_device] (bus: 3, addr: 4, depth: 1, port: 6): '\\.\USB#VID_17EF&PID_480F#6&3AF1EAA2&0&6' libusb:debug [windows_get_device_list] extra GUID: {FF440353-416E-4E94-8C66-74F173A81039} libusb:debug [windows_get_device_list] allocating new device for session [379] libusb:debug [init_device] got bus number from ancestor #2 libusb:warning [init_device] could not get node connection information for device '\\.\USB#VID_224F&PID_0001#6&12E571E8&0&4': [87] The parameter is incorrect. libusb:debug [windows_get_device_list] allocating new device for session [3BD] libusb:debug [init_device] got bus number from ancestor #2 libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 46 bytes) libusb:debug [init_device] (bus: 2, addr: 2, depth: 1, port: 3): '\\.\USB#VID_8086&PID_0187#6&19D2BC7A&0&3' libusb:debug [windows_get_device_list] found existing device for session [3E4] (3.0) libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 25 bytes) libusb:debug [init_device] (bus: 3, addr: 1, depth: 1, port: 1): '\\.\USB#VID_8087&PID_0020#5&3C7F0E4&0&1' libusb:debug [windows_get_device_list] found existing device for session [83] (2.0) libusb:debug [init_device] found 1 configurations (active conf: 1) libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurationValue=1, 25 bytes) libusb:debug [init_device] (bus: 2, addr: 1, depth: 1, port: 1): '\\.\USB#VID_8087&PID_0020#5&CF3B5E&0&1' libusb:debug [get_api_type] driver(s): WUDFRD libusb:debug [get_api_type] lower filter driver(s): WINUSB libusb:debug [get_api_type] matched lower filter driver name against WinUSB API libusb:debug [windows_get_device_list] found existing device for session [4B] (3.3) libusb:debug [get_api_type] driver(s): USBCCGP libusb:debug [get_api_type] matched driver name against Composite API libusb:debug [windows_get_device_list] found existing device for session [2F3] (3.4) libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [windows_get_device_list] found existing device for session [379] (1.0) libusb:debug [get_api_type] driver(s): BPUSB libusb:debug [windows_get_device_list] found existing device for session [3BD] (2.2) libusb:debug [get_api_type] driver(s): WINUSB libusb:debug [get_api_type] matched driver name against WinUSB API libusb:debug [libusb_unref_device] destroy device 1.0 libusb:debug [libusb_unref_device] destroy device 2.0 libusb:debug [libusb_unref_device] destroy device 3.0 libusb:debug [libusb_unref_device] destroy device 1.0 libusb:debug [libusb_unref_device] destroy device 1.0 libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_get_device_descriptor] libusb:debug [libusb_unref_device] destroy device 2.255 libusb:debug [libusb_unref_device] destroy device 3.255 libusb:debug [libusb_unref_device] destroy device 3.3 libusb:debug [libusb_unref_device] destroy device 3.4 libusb:debug [libusb_unref_device] destroy device 2.2 libusb:debug [libusb_unref_device] destroy device 3.1 libusb:debug [libusb_unref_device] destroy device 2.1 On Wed, Jun 8, 2011 at 9:49 AM, Tim Roberts <ti...@pr...> wrote: > Pete Batard wrote: >>> libusb:debug [windows_get_device_list] allocating new device for session [2FE] >>> libusb:debug [get_api_type] driver(s): NUSB3HUB >>> libusb:debug [windows_get_device_list] allocating new device for session [3EB] >>> libusb:debug [get_api_type] driver(s): USBHUB >>> libusb:debug [get_api_type] matched driver name against HUB API >> From the information above, I think the problem is that the current >> backend does not handle USB 3.0 hubs, as I wasn't aware Microsoft had >> changed their hub driver service name from "USBHUB" to "NUSB3HUB" until now. > > They have not done so. NUSB3HUB.SYS is a USB 3.0 hub driver written by > NEC, not by Microsoft. There is no USB 3.0 support from Microsoft as of > yet. If you're running USB 3 on Windows, you are running a host > controller driver and hub drivers written by the manufacturer. No one > has any idea whether these manufacturer-specific drivers are following > Microsoft's rules, or rules of their own, and there is no documentation. > > USB 3.0 on Windows must be considered experimental at this point. It's > the wild, wild west. It's not clear that it is beneficial to make any > major changes based on the USB 3 code in the wild. > > -- > Tim Roberts, ti...@pr... > Providenza & Boekelheide, Inc. > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |
From: Pete B. <pb...@gm...> - 2011-06-09 10:31:37
|
On 2011.06.09 01:17, Dave Camarillo wrote: > libusb:warning [init_device] could not get node connection information > for device '\\.\USB#VID_224F&PID_0001#6&12E571E8&0&4': [87] The > parameter is incorrect. By the looks of it, the NUSB3HUB.SYS driver does not support IOCTL_USB_GET_NODE_CONNECTION_INFORMATION then, so we'll have to figure something out... I have just ordered a NEC based USB 3.0 card, along with a 3.0 hub, to see what I can do (though it'll probably be a month before I get them). In the meantime, you probably want to follow Tim's advice and consider that, as long as it remains non officially supported in Windows, USB 3.0 should be flagged as experimental, and advise your users to switch to a 2.0 port if they find that their device doesn't work with 3.0 one. Regards, /Pete PS: You may want to add the 224F VID ("APDM" I assume) to the list of known USB VIDs at http://www.linux-usb.org/usb-ids.html. This list is used by many people and applications (including libwdi) and it'll help users better identify their USB devices. |
From: Dave C. <dav...@gm...> - 2011-06-09 18:45:53
|
Agreed, we'll stick with USB 2.0 for now and keep an eye on the mailing list for 3.0 related stuff... Thanks for looking into this... Also, thanks for the pointer to the USB id list. I've submitted our VID/PID information to the database... Best Regards, -Dave On Thu, Jun 9, 2011 at 2:31 AM, Pete Batard <pb...@gm...> wrote: > On 2011.06.09 01:17, Dave Camarillo wrote: >> libusb:warning [init_device] could not get node connection information >> for device '\\.\USB#VID_224F&PID_0001#6&12E571E8&0&4': [87] The >> parameter is incorrect. > > By the looks of it, the NUSB3HUB.SYS driver does not support > IOCTL_USB_GET_NODE_CONNECTION_INFORMATION then, so we'll have to figure > something out... > > I have just ordered a NEC based USB 3.0 card, along with a 3.0 hub, to > see what I can do (though it'll probably be a month before I get them). > In the meantime, you probably want to follow Tim's advice and consider > that, as long as it remains non officially supported in Windows, USB 3.0 > should be flagged as experimental, and advise your users to switch to a > 2.0 port if they find that their device doesn't work with 3.0 one. > > Regards, > > /Pete > > PS: You may want to add the 224F VID ("APDM" I assume) to the list of > known USB VIDs at http://www.linux-usb.org/usb-ids.html. This list is > used by many people and applications (including libwdi) and it'll help > users better identify their USB devices. > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |
From: Xiaofan C. <xia...@gm...> - 2011-06-10 06:07:09
|
On Thu, Jun 9, 2011 at 5:31 PM, Pete Batard <pb...@gm...> wrote: > On 2011.06.09 01:17, Dave Camarillo wrote: >> libusb:warning [init_device] could not get node connection information >> for device '\\.\USB#VID_224F&PID_0001#6&12E571E8&0&4': [87] The >> parameter is incorrect. > > By the looks of it, the NUSB3HUB.SYS driver does not support > IOCTL_USB_GET_NODE_CONNECTION_INFORMATION then, so we'll have to figure > something out... Is this node connection information strictly necessary? > I have just ordered a NEC based USB 3.0 card, along with a 3.0 hub, to > see what I can do (though it'll probably be a month before I get them). I am thinking of getting an add-in card as well now that I have two USB 3.0 external hard-disks but no PCs with the xHCI host controller. NEC/Renesas (uPD720200A) seems to be the most popular now. But there are other vendors like TI (TUSB7340), FrescoLogic (FL1009/FL1000), Via (VL800) and others. There there will be AMD A75 and A70M Fusion chipset and Intel Panther Point which will probably bring USB 3.0 to the mass market finally. There are actually codes in the linux-usb mailing list to support Panther Point already. > In the meantime, you probably want to follow Tim's advice and consider > that, as long as it remains non officially supported in Windows, USB 3.0 > should be flagged as experimental, and advise your users to switch to a > 2.0 port if they find that their device doesn't work with 3.0 one. Maybe Windows 8 will be released next year with USB 3.0 support and we will get official USB 3.0 support for Windows 7 as well (not so sure about XP and Vista). -- Xiaofan |
From: Pete B. <pb...@gm...> - 2011-06-10 11:26:02
|
On 2011.06.10 07:07, Xiaofan Chen wrote: >> By the looks of it, the NUSB3HUB.SYS driver does not support >> IOCTL_USB_GET_NODE_CONNECTION_INFORMATION then, so we'll have to figure >> something out... > > Is this node connection information strictly necessary? As you or Travis are undoubtedly aware, this could probably be avoided by hooking into the Windows registry directly (though we'd need to check if NUSB3HUB.SYS implementation carries the same level of information there as Microsoft). However, as Tim advocated when we started working on the Windows backend, the Windows implementation needs to steer away from bypassing API calls and hook into the registry directly, as there is no guarantee that this information is not going to be reshuffled by Microsoft in later OS releases, therefore keeping to using known API calls and ioctls to retrieve data is the only safe way we have to ensure that libusb should work on Windows 8 and late. But more realistically, I'd say, if we start bypassing official APIs and IOCTLs, and start working with the registry directly, we might very well go all the way and ditch SetupAPI altogether in the process, as we could have a much more efficient and simpler enumeration then. Anyway, once I get the relevant hardware, I'll have a closer look since this issue is now on my internal bug list. If someone wants to log an official bug for it, they are also welcome to do so. > I am thinking of getting an add-in card as well now that I have two > USB 3.0 external hard-disks but no PCs with the xHCI host controller. > NEC/Renesas (uPD720200A) seems to be the most popular now. But there > are other vendors like TI (TUSB7340), FrescoLogic (FL1009/FL1000), > Via (VL800) and others. Good info. Thanks! I'll have a look at the drivers provided by TI and Frescologic, to find out if, at the very least, we need to add new hub services to our list. > There there will be AMD A75 and A70M Fusion > chipset and Intel Panther Point which will probably bring > USB 3.0 to the mass market finally. Yeah, I've heard about the AMD development. Somehow Intel are very late in the game, which is a bit surprising. Regards, /Pete |
From: Xiaofan C. <xia...@gm...> - 2011-06-12 00:42:39
|
On Fri, Jun 10, 2011 at 7:25 PM, Pete Batard <pb...@gm...> wrote: > On 2011.06.10 07:07, Xiaofan Chen wrote: >> I am thinking of getting an add-in card as well now that I have two >> USB 3.0 external hard-disks but no PCs with the xHCI host controller. >> NEC/Renesas (uPD720200A) seems to be the most popular now. But there >> are other vendors like TI (TUSB7340), FrescoLogic (FL1009/FL1000), >> Via (VL800) and others. > > Good info. Thanks! > I'll have a look at the drivers provided by TI and Frescologic, to find > out if, at the very least, we need to add new hub services to our list. Another one by Etron (EJ168). This seems to be used in several motherboards as well. http://www.etron.com/SystemICs-detal.php?ID=1 Yet another one by ASMedia (ASM1042). http://www.asmedia.com.tw/eng/e_show_products.php?item=100 Linux seems to support most of the xHCI controllers. I think Mac does not support USB 3.0 now other than this. http://www.lacie.com/us/more/index.htm?id=10112 >> There there will be AMD A75 and A70M Fusion >> chipset and Intel Panther Point which will probably bring >> USB 3.0 to the mass market finally. > > Yeah, I've heard about the AMD development. Somehow Intel are very late > in the game, which is a bit surprising. Maybe they want to delay USB 3.0 so that their Thunderbolt (aka Light Peak) can get mature (now used by Apple). -- Xiaofan |
From: Xiaofan C. <xia...@gm...> - 2011-06-15 06:54:39
|
On Fri, Jun 10, 2011 at 7:25 PM, Pete Batard <pb...@gm...> wrote: > On 2011.06.10 07:07, Xiaofan Chen wrote: >>> By the looks of it, the NUSB3HUB.SYS driver does not support >>> IOCTL_USB_GET_NODE_CONNECTION_INFORMATION then, so we'll have to figure >>> something out... >> >> Is this node connection information strictly necessary? > > As you or Travis are undoubtedly aware, this could probably be avoided > by hooking into the Windows registry directly (though we'd need to check > if NUSB3HUB.SYS implementation carries the same level of information > there as Microsoft). However, as Tim advocated when we started working > on the Windows backend, the Windows implementation needs to steer away > from bypassing API calls and hook into the registry directly, as there > is no guarantee that this information is not going to be reshuffled by > Microsoft in later OS releases, therefore keeping to using known API > calls and ioctls to retrieve data is the only safe way we have to ensure > that libusb should work on Windows 8 and late. > > But more realistically, I'd say, if we start bypassing official APIs and > IOCTLs, and start working with the registry directly, we might very well > go all the way and ditch SetupAPI altogether in the process, as we could > have a much more efficient and simpler enumeration then. I am not talking about ditching SetupAPI, but just wondering if we really need to talk to the hub (control transfer) to get such information. For example, if we still use SetupAPI, but with the following function (SetupDiGetDeviceRegistryProperty), can we get enough information? http://msdn.microsoft.com/en-us/library/ff551967%28v=vs.85%29.aspx -- Xiaofan |
From: Pete B. <pb...@gm...> - 2011-06-15 10:29:05
|
On 2011.06.15 07:54, Xiaofan Chen wrote: > I am not talking about ditching SetupAPI, but just wondering if we really > need to talk to the hub (control transfer) to get such information. For > example, if we still use SetupAPI, but with the following function > (SetupDiGetDeviceRegistryProperty), can we get enough information? > http://msdn.microsoft.com/en-us/library/ff551967%28v=vs.85%29.aspx I appreciate the help, and I'm planning to look more closely into this once I get my USB 3.0 hardware. Currently, this is the information we use from the USB_NODE_CONNECTION_INFORMATION structure returned by the ioctl call [1]: o ConnectionStatus: to find if a device is still connected. I don't think we can get this information that easily with SetupAPI, as SetupAPI is ill suited to query data for children of a hub. Instead it requires an instance for the child themselves, which of course makes the whole thing tricky when you want to detect if a device exists or not. On the other hand, I don't believe we have an absolute need to check the connection status here. We could probably let a later call fail. o DeviceAddress: can be gotten from SetupAPI... though it requires getting it from the device itself, rather than its parent, so this would be more complicated to obtain. o DeviceDescriptor: this is our main meal, as we need to cache those during enum (which as you know is a requirement that libusbK's enum does not have). ATM, I don't know how the device descriptor can be gotten easily (or at all) with SetupAPI, since SetupAPI is meant to be protocol agnostic. Once Hans' get_speed() patch is in, we'll also use that call to retrieve the device speed, which I don't think SetupAPI can provide either. I also remember introducing ioctls in the code as last resort when I found that SetupAPI was not enough to comply with the libusb-1.0 requirements - using SetupAPI all the way was something I strived for too. Anyway, there'll be more on USB 3.0 support with libsub-1.0/Windows soon. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/ff540090%28v=vs.85%29.aspx |
From: Xiaofan C. <xia...@gm...> - 2011-06-23 13:43:39
|
On Wed, Jun 15, 2011 at 6:29 PM, Pete Batard <pb...@gm...> wrote: > Currently, this is the information we use from the > USB_NODE_CONNECTION_INFORMATION structure returned by the ioctl call [1]: > > o ConnectionStatus: to find if a device is still connected. I don't > think we can get this information that easily with SetupAPI, as SetupAPI > is ill suited to query data for children of a hub. Instead it requires > an instance for the child themselves, which of course makes the whole > thing tricky when you want to detect if a device exists or not. On the > other hand, I don't believe we have an absolute need to check the > connection status here. We could probably let a later call fail. > > o DeviceAddress: can be gotten from SetupAPI... though it requires > getting it from the device itself, rather than its parent, so this would > be more complicated to obtain. > > o DeviceDescriptor: this is our main meal, as we need to cache those > during enum (which as you know is a requirement that libusbK's enum does > not have). ATM, I don't know how the device descriptor can be gotten > easily (or at all) with SetupAPI, since SetupAPI is meant to be protocol > agnostic. > > Once Hans' get_speed() patch is in, we'll also use that call to retrieve > the device speed, which I don't think SetupAPI can provide either. I > also remember introducing ioctls in the code as last resort when I found > that SetupAPI was not enough to comply with the libusb-1.0 requirements > - using SetupAPI all the way was something I strived for too. I think in this thread Tim mentioned that it is better to use SetupAPI and not the registry based approach for the device list function. http://libusb.6.n5.nabble.com/proposed-changes-to-core-for-Windows-quot-poll-quot-support-td5529.html However, he also mentioned the following. "One potential implementation strategy would be to define a single device interface GUID to be used by all Libusb/WinUSB devices. That would be a solution quite close to the Linux strategy; you would enumerate through all of the devices in the "Libusb/WinUSB" interface class, and let the apps do their picking by VID/PID. I had been assuming that was your strategy." Say if we are going to develop a new generic USB library but make some uses of the libusb-1.0 Windows implementation. If we still use SetupAPI for device list, will the above approach saves us the problem in using IOCTL_USB_GET_NODE_CONNECTION_INFORMATION? Do we still need to disturb the hub to get the required information? Or is this a limitation of WinUSB? If yes then if we ditch WinUSB and use only libusbk.sys (and libusb0.sys), then no issues. > Anyway, there'll be more on USB 3.0 support with libsub-1.0/Windows soon. > Any updates? FYI, Travis tried out USB 3.0 host controller based on NEC and it seems that libusb0.dll and libusbk.dll both work fine. -- Xiaofan |
From: Pete B. <pb...@gm...> - 2011-06-23 15:55:08
|
On 2011.06.23 14:43, Xiaofan Chen wrote: > "One potential implementation strategy would be to define a single device > interface GUID to be used by all Libusb/WinUSB devices. That would be a > solution quite close to the Linux strategy; you would enumerate through > all of the devices in the "Libusb/WinUSB" interface class, and let the > apps do their picking by VID/PID. I had been assuming that was your > strategy." Personally, I don't see _forcing_ a single interface class GUID for all the libusb devices we want to support as a good idea, and that's the reason why I didn't go for it during design. It restricts both the freedom of use and flexibility of libusb on Windows. This is especially true for WinUSB, where someone may already have installed the driver using whatever class GUID, and we would have to force them to reinstall the exact same thing, just to update that single GUID (as well as force them to revert again if they want to use the original app). I know Jan Axelson has been doing some enforcing of GUIDs in the WinUSB samples provided on the lakeview site (IIRC the samples went as far as forcing test devices to use the exact same interface GUID rather instead of just the class GUID), but unless you don't have any other choice, or you're demonstrating something, this is a practice I really wouldn't encourage. Even for libusb0 or libusbK, we have no guarantee that the class GUID will be the one we pick, lest we _force_ everybody to install their drivers using only the installers we provide. As much as I want people to use libwdi, I still prefer giving them the choice not to use it, if they think it doesn't suit their need. For instance, someone might want to build an application for a set of devices they designed, and use a custom driver install that sets the class GUID to group similar devices into specific categories for easier processing by their application, to provide some form of future proofing (each class GUID would support the same mode of access). If we force them to use our class GUID, they have to maintain a list of which PID belong to which category, and must update the app for each new PID. Experience tells that no matter how thorough you think you've been in envisioning the uses of an app or library, there always exists some usage you haven't fathomed, that warrants doing things in a very different fashion. Therefore flexibility matters. Not relying on a single GUID class, as we could have done, is adding flexibility to libusb, and that's something very desirable. > If we still use SetupAPI for device list, will the above approach saves us the > problem in using IOCTL_USB_GET_NODE_CONNECTION_INFORMATION? I don't believe it will. At least the retrieval of the speed information and device descriptor is not something we can get from SetupAPI alone, from what I could see, so we will always have to query the hub... for whom the class GUID of its children is irrelevant. > Or is this a limitation of WinUSB? If yes then if we ditch WinUSB and use only > libusbk.sys (and libusb0.sys), then no issues. Since they can talk to the device without being filtered, I guess libusbK or libusb0 can have access to speed data and descriptor directly. However, the idea of ditching something that adds to the flexibility of our library simply because it has limitations, as we did with HID, is and remains utterly idiotic as it does not benefit our users one bit, on the contrary. It only benefits ourselves, by making our life easier, which, IMO, has to be one of the worst reason to ever want to change the targeted feature-set of our software... What would you prefer? A library that says: "You can use either WinUSB or libusb0/K. If you find that you can't access devices USB 3.0 devices using WinUSB (which, again, is a limitation we currently have no proof we won't be able to work around), try switching to libusb0/K" or one that says: "You MUST use libusb0/K always"? Now, people will argue that limiting users options can actually be beneficial for them, but they tend to forget about setting defaults (eg: recommending/defaulting to a K/0 driver installation when using our tools for people who may not be able to easily decide which one to use) and encouraging people to use those, while still giving them a choice. Seriously, and I really hope everybody on this list can at least understand this view (else don't be surprised to see more heated mail from me in the future) users come first. Always. Making things easier from a development and support standpoint comes waaaaay second, and currently, ditching WinUSB is all about the latter. Plus, as you know, we have commercial users that have begun shipping products relying on libusb-1.0/WinUSB (and who aren't using libwdi for their WinUSB driver installation), so we can't just ditch WinUSB without an appropriate transition period anyway. >> Anyway, there'll be more on USB 3.0 support with libsub-1.0/Windows soon. > > Any updates? Still waiting on the hardware to arrive. As I indicated, I don't expect it to arrive less than a month after the order. This is from experience, not speculation. > FYI, Travis tried out USB 3.0 host controller based on NEC and it seems > that libusb0.dll and libusbk.dll both work fine. That's great. Not entirely surprising though, since you aren't limited to what SetupAPI alone can provide. Regards, /Pete |
From: Xiaofan C. <xia...@gm...> - 2011-06-24 01:11:00
|
On Thu, Jun 23, 2011 at 11:55 PM, Pete Batard <pb...@gm...> wrote: > Since they can talk to the device without being filtered, I guess > libusbK or libusb0 can have access to speed data and descriptor directly. > > However, the idea of ditching something that adds to the flexibility of > our library simply because it has limitations, as we did with HID, is > and remains utterly idiotic as it does not benefit our users one bit, on > the contrary. It only benefits ourselves, by making our life easier, > which, IMO, has to be one of the worst reason to ever want to change the > targeted feature-set of our software... > > What would you prefer? A library that says: "You can use either WinUSB > or libusb0/K. If you find that you can't access devices USB 3.0 devices > using WinUSB (which, again, is a limitation we currently have no proof > we won't be able to work around), try switching to libusb0/K" or one > that says: "You MUST use libusb0/K always"? Now, people will argue that > limiting users options can actually be beneficial for them, but they > tend to forget about setting defaults (eg: recommending/defaulting to a > K/0 driver installation when using our tools for people who may not be > able to easily decide which one to use) and encouraging people to use > those, while still giving them a choice. > > Seriously, and I really hope everybody on this list can at least > understand this view (else don't be surprised to see more heated mail > from me in the future) users come first. Always. > Making things easier from a development and support standpoint comes > waaaaay second, and currently, ditching WinUSB is all about the latter. > Plus, as you know, we have commercial users that have begun shipping > products relying on libusb-1.0/WinUSB (and who aren't using libwdi for > their WinUSB driver installation), so we can't just ditch WinUSB without > an appropriate transition period anyway. I see your point. And I am actually not really talking about libusb-1.0 Windows backend here. That has been done by you with a lot of efforts and I see no point of changing the fundamental implementation other than optimization here and there. I said the following. >>Say if we are going to develop a new generic USB library but make >>some uses of the libusb-1.0 Windows implementation. >> >>If we still use SetupAPI for device list, will the above approach saves us the >> problem in using IOCTL_USB_GET_NODE_CONNECTION_INFORMATION? >> Do we still need to disturb the hub to get the required information? >> >> Or is this a limitation of WinUSB? If yes then if we ditch WinUSB and use only >> libusbk.sys (and libusb0.sys), then no issues. So it seems that another general USB library (like OpenUSB or a new one) can benefit from the above discussion by not using WinUSB and not to have the limitations you are facing in the libusb-1.0 Windows backend. I think SetupAPI can still be used in that case if the developer of that new library uses libusbk.sys or his new generic driver. -- Xiaofan |
From: Pete B. <pb...@gm...> - 2011-06-24 10:17:30
|
On 2011.06.24 02:10, Xiaofan Chen wrote: > I said the following. >>> Say if we are going to develop a new generic USB library Ah OK. Missed the most important part there. > So it seems that another general USB library (like OpenUSB or a new one) > can benefit from the above discussion by not using WinUSB and not to > have the limitations you are facing in the libusb-1.0 Windows backend. > > I think SetupAPI can still be used in that case if the developer of that > new library uses libusbk.sys or his new generic driver. If I were to develop a new library, here's what I'd do: 1. pick up the relevant parts from the libusb-1.0 and libusbK DLLs and create a _single_ library. There really is no point with installing another DLL ontop of libusbK, or one beneath whatever new library you are going to write, if both the driver you use and library are open source. I'd also make sure users can produce a static version of the library. 2. keep some form of WinUSB driver+DLL backwards compatibility, like what libusbK is currently doing, even with the known limitations of WinUSB. My understanding from what Travis did with the K implementation is that it wasn't too difficult to achieve. If nothing else, it can help with trying to isolate an issue that may be specific to a driver ("do you see the same issue if you try the other driver?"). But, in the absence of user requests for WinUSB, that decision can be left to the person who writes the library. 3. Avoid SetupAPI like the plague, and fetch the USB device information directly from the registry. From where I stand, SetupAPI is an half assed implementation, that doesn't even manage to properly supersede the API (CM) it was meant to replace (so currently, libusb-1.0/Windows has to use a mix of both), and that is ill suited for fast and efficient USB enumeration or hotplug support. I'm well aware nobody likes the 1.0/Windows enumeration (old or new) and for good reason: It adds a lot of overhead, for extremely little benefit. The only thing SetupAPI has for it, really, is that it's supposed to be future proof. But so is any OSS library anyway, even if it relies on APIs that may not be future-proof, in that, if the OS changes access to the data the library requires, the problem will be immediately identified and, provided the project is alive enough (else you're probably better off not using that library in the first place), a fix will be produced. Of course, that's just my view for an hypothetical new library. It doesn't mean the above will apply to future implementations of the current libusb-1.0/Windows library. Regards, /Pete |
From: Tim R. <ti...@pr...> - 2011-06-24 18:11:30
|
Pete Batard wrote: > > 3. Avoid SetupAPI like the plague, and fetch the USB device information > directly from the registry. From where I stand, SetupAPI is an half > assed implementation, that doesn't even manage to properly supersede the > API (CM) it was meant to replace (so currently, libusb-1.0/Windows has > to use a mix of both), and that is ill suited for fast and efficient USB > enumeration or hotplug support. This is neither fair nor accurate. The biggest technical problem with SetupAPI is that it is verbose. It requires a lot of lines of non-obvious code to accomplish anything. It serves its purpose well, once you finish typing, but it's cut-and-paste coding. I have a pretty fair understanding of SetupAPI, but I cannot write code that uses it from scratch. However, the bigger problem is that we are trying to shove a square peg into a round hole. Libusb undeniably has a Linux heritage, and its philosophy is strongly oriented towards the Linux way of doing things, which are very different from the world of Windows devices. The concept of "show me every device in the system so I can find mine," which is found in the driver stack for virtually every Linux bus type, is foreign to Windows. It does not scale well. It requires each driver/application to have knowledge of the internal workings of its bus -- information that it should not need to have. Windows abstracts all that, so that a driver merely says "this is my device", and it's up to PnP and the Device Manager to do the searching and the matching, and the hotplug management. We are battling that abstraction. I'm not saying I have an answer. There is an impedance mismatch here that is, in large part, unresolvable. As long as libusb tries to pretend that it is offers the Linux philosophy on Windows, there will be ugliness underneath, and it's not going to get better. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Xiaofan C. <xia...@gm...> - 2011-06-25 00:45:05
|
On Sat, Jun 25, 2011 at 2:11 AM, Tim Roberts <ti...@pr...> wrote: > Pete Batard wrote: >> >> 3. Avoid SetupAPI like the plague, and fetch the USB device information >> directly from the registry. From where I stand, SetupAPI is an half >> assed implementation, that doesn't even manage to properly supersede the >> API (CM) it was meant to replace (so currently, libusb-1.0/Windows has >> to use a mix of both), and that is ill suited for fast and efficient USB >> enumeration or hotplug support. > > This is neither fair nor accurate. The biggest technical problem with > SetupAPI is that it is verbose. It requires a lot of lines of > non-obvious code to accomplish anything. It serves its purpose well, > once you finish typing, but it's cut-and-paste coding. I have a pretty > fair understanding of SetupAPI, but I cannot write code that uses it > from scratch. I tend to agree. It seems a lot of the codes are lying on the internet, the famous one comes from Jan Axelson because of the popularity of her book "USB Complete" which is good but not complete at all. :-) > However, the bigger problem is that we are trying to shove a square peg > into a round hole. Libusb undeniably has a Linux heritage, and its > philosophy is strongly oriented towards the Linux way of doing things, > which are very different from the world of Windows devices. The concept > of "show me every device in the system so I can find mine," which is > found in the driver stack for virtually every Linux bus type, is foreign > to Windows. It does not scale well. It requires each > driver/application to have knowledge of the internal workings of its bus > -- information that it should not need to have. Windows abstracts all > that, so that a driver merely says "this is my device", and it's up to > PnP and the Device Manager to do the searching and the matching, and the > hotplug management. We are battling that abstraction. I think libusb-win32 and libusbk works well in this aspect by following this Windows way -- we only care about the device that the drivers (libusb0.sys, libusbk.sys winusb.sys) support, not all the USB devices. libusb-win32 and libusbk are both Windows only. Actually Pete also has some codes for libwdi to enumerate USB device which is quite different from the libusb-1.0 Windows backend codes. libwdi is also Windows only. Pete's current implementation falls in what you mentioned. I think it is not bad actually since the libusb maintainers want the libusb-1.0 Windows backend to behave like the Linux side if possible. And I think this is not that unreasonable as libusb is positioned as a cross-platform library. So there will be compromises and sometimes the lowest common denominator needs to be adopted even at the expenses of performance or beauty of the codes. Actually libusb-win32 filter is kind of Stephan's way of supporting all USB device, but that apparently is not working well and caused lots of BSODs before Travis and I took over the project. Now we only recommend the use of the filter to work as a filter for some specific USB device the user is interested to interact with, but not to use as a class filter, or as a filter for all the USB class/device. BTW, WinUSB supports an API to get device speed. So if only WinUSB support is needed, then IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX is not necessary to be used to get device speed. > I'm not saying I have an answer. There is an impedance mismatch here > that is, in large part, unresolvable. As long as libusb tries to > pretend that it is offers the Linux philosophy on Windows, there will be > ugliness underneath, and it's not going to get better. As long as the ugliness is under the hood, I think there is no big issue for the library users. :-) In general, I sympathize with what Pete's difficult decisions when trying to emulate the Linux libusb behavior. It is also good to have something working reasonably well (like Pete's current implementation), and then do some form of optimization here and there without changing the fundamental implementation methodologies. Then probably learn from the lessons and then change the implementation methodologies when doing a different project -- Xiaofan |
From: Pete B. <pb...@gm...> - 2011-06-25 21:41:16
|
On 2011.06.24 19:11, Tim Roberts wrote: >> 3. Avoid SetupAPI like the plague, and fetch the USB device information >> directly from the registry. From where I stand, SetupAPI is an half >> assed implementation, that doesn't even manage to properly supersede the >> API (CM) it was meant to replace (so currently, libusb-1.0/Windows has >> to use a mix of both), and that is ill suited for fast and efficient USB >> enumeration or hotplug support. > > This is neither fair nor accurate. The biggest technical problem with > SetupAPI is that it is verbose. That's not really the problem I have with it. Verbose yet generic is not much of an issue for a developer, unless it impacts performance. My problem, and it looks like this is something you agree with, is that SetupAPI is anything but generic: it restricts developers to using a very specific model without offering any path outside of it, and I still don't see much of a valid reason for Microsoft to do so. > However, the bigger problem is that we are trying to shove a square peg > into a round hole. Exactly. Microsoft is telling developers using its API: "You _must_ use round pegs and nothing else". So in essence, the API loses all pretence of genericity. Unfortunately, what developers do expect from an OS API is for it to be as generic as possible. The goal of any OS API should be to give developers as much freedom as they want to achieve their tasks, and only be there to facilitate access to the underlying hardware, not limit it. If one of the goals of an OS API becomes the enforcing of a specific abstraction, when it doesn't have to, then I believe it misses the point. For instance, SetupAPI is now (indirectly) telling developers: "You should never need to access the parent of a device", as it doesn't provide any API call to do so. Well, if that's what the API wants to assume, then it's going too far as it is now restricting what developers might have a very legitimate reason for wanting to do. This is even more damaging as the API it is supposed to supersede (CM) did provide such calls, so in effect it's a matter of Microsoft telling people that whatever they suggested or allowed with the previous API was wrong. There's also the whole business of SetupAPI being next to useless for driverless devices when its origins should at least make it partially aimed at helping with tasks such as driver installation. As such, dealing with driverless devices, and retrieving as much of their properties as possible, should not be as out of the equation as it is right now. All in all, I see limitations here, more limitations there, none of which make much sense since they provide extremely little benefit (expect for Microsoft, since they have now limited the scope of what they have to support with the API). Therefore I contend that SetupAPI does fall short of expectations of an API that can help with device enumeration and installation in a generic fashion, and that one is better off not using it for such a task. I also surmise that, with SetupAPI, Microsoft went through the enforcing of an abstraction model that one could not deviate from, because it was easier and required less effort than providing an API that offered the expected level of freedom and generic access for developers, hence "half assed". > The concept > of "show me every device in the system so I can find mine," which is > found in the driver stack for virtually every Linux bus type, is foreign > to Windows. Yes. But it is also the most straightforward and generic way of locating a device, and the first approach a lot of developers would tend to think of when left to their own devices (no pun intended). So I don't think the concept should be that foreign even to Windows developers. > It does not scale well. You do have a point there, but I don't see scaling alone as compelling reason to forbid such use altogether, especially for a task such as enumeration, that in most cases would only run once (then hotplug can take the relay). The percentage of developers affected by the scaling issue is expected to be very low. How many people run Windows boxes with hundreds of devices to sort out? > It requires each > driver/application to have knowledge of the internal workings of its bus > -- information that it should not need to have. Then who gets to decide the kind of information developers should and shouldn't deal with? Was there any form of consultation with said developers? As I said before, there's no way the designer of an API can foresee all of its uses. Arbitrarily restricting the information developers can have access to, or enforcing the use of a specific abstraction, because someone thinks nobody should have knowledge of the internal workings of a bus, is a dangerous approach IMO. The trend towards total abstraction of hardware knowledge is only one that makes sense when you're dealing with end users, as some of them are expected to be "technologically challenged". With an API, not so much. > Windows abstracts all > that, so that a driver merely says "this is my device", and it's up to > PnP and the Device Manager to do the searching and the matching, and the > hotplug management. We are battling that abstraction. Indeed. Unfortunately Microsoft has some history on deciding, on their own, what users and developers can have access to, and it hasn't always been for the best. From my experience with libusb/Windows, forcing the SetupAPI abstraction model is another case where it doesn't work well. The libusb approach for device identification, even if it comes from Linux, is not an unreasonable one to have. To me, having an API that pretends it is, is. > I'm not saying I have an answer. There is an impedance mismatch here > that is, in large part, unresolvable. As long as libusb tries to > pretend that it is offers the Linux philosophy on Windows, there will be > ugliness underneath, and it's not going to get better. Well, as Microsoft should be fully aware, especially with the NT/VMS roots of its later OSes, it's not always a bad thing to lift up a few elements from what others are doing, when they might be doing things better. Besides, unlike the Windows SetupAPI implementation, the Linux API for enumerating devices left plenty of room for user and developer feedback before being agreed upon, which, in my book, trumps anything that gets decided by a handful of people in a proprietary fashion, no matter how smart. Regards, /Pete |
From: Travis <tra...@co...> - 2011-06-25 22:54:15
|
On 6/25/2011 2:41 PM, Pete Batard wrote: >> The concept >> > of "show me every device in the system so I can find mine," which is >> > found in the driver stack for virtually every Linux bus type, is foreign >> > to Windows. Windows does a good job of managing all of this for you. I think many developers even hard-code symbolic links and interface guids directly in. There is simply no need for a device list because the system works. I'm rather happy with what Microsoft has done with device interface guids because a single guid can provide all the information needed; including making it simple to enable guild-specific hot-plug detection. > Yes. But it is also the most straightforward and generic way of locating > a device, and the first approach a lot of developers would tend to think > of when left to their own devices (no pun intended). So I don't think > the concept should be that foreign even to Windows developers. > It's a neat "show me how it works" idea, but every usb application cannot query all usb devices just to find a single device. You have no way of knowing what devices might be doing, they might be flashing firmware or something even more critical like recording the X-Files. Sneaking control transfers around a driver you know nothing about is asking for it. I think the good idea is to have a device list that gives you a vid, pid, and a serial-number/unique ID; product and mfu strings would be a bonus. That's really all you need at the "list" stage. Windows can do this with no extra I/O no problem; as many times as you want it. ;) I'm trying to figure out how to get linux-libusb-1.0 to give all this info up without extra I/O, but it seems it cannot do it. Regards, Travis |
From: Pete B. <pb...@gm...> - 2011-06-26 01:08:32
|
On 2011.06.25 23:54, Travis wrote: > I'm rather happy with what Microsoft has done with device > interface guids because a single guid can provide all the information > needed; including making it simple to enable guild-specific hot-plug > detection. Come back to me when you have tried using Microsoft's hotplug detection with driverless devices. Then I'd like to hear what you think about device interface GUIDs. Wanna know if a driverless device was either inserted or removed? With Microsoft, and because driverless has no GUID, you just can't (unless you maintain your own list and do a whole enum everytime there's an hotplug event, to figure out if a device appeared or disappeared has changed). Yeah, it's a specific problem (which you don't have to bother with in K), but exactly the kind of problem you "ask for" when you provide an API that is not generic enough... Or is the expectation to have the same level of hotplugging information for driverless devices as non-driverless provide not a reasonable one? >> Yes. But it is also the most straightforward and generic way of locating >> a device, and the first approach a lot of developers would tend to think >> of when left to their own devices (no pun intended). So I don't think >> the concept should be that foreign even to Windows developers. >> > > It's a neat "show me how it works" idea, but every usb application > cannot query all usb devices just to find a single device. You're assuming the enumerating equates querying. That should not the case. We're talking about SetupAPI and its limitations here, and the last thing anybody wants SetupAPI to do is query the device. The generic API I envision shouldn't have to. So the argument above is still valid: with a proper API, that doesn't result in someone having to query devices separately, the approach above shouldn't be an issue. Nobody in their right mind will want to build a device enumeration that queries devices individually. Instead, what they want, and this is my main gripe with SetupAPI, is an OS API that provides access to _all_ of the device related information that the OS retrieved when it first detected the device, even one that is specific to the type of bus being used. > You have no > way of knowing what devices might be doing, they might be flashing > firmware or something even more critical like recording the X-Files. > Sneaking control transfers around a driver you know nothing about is > asking for it. Exactly my point! The only reason we have to do this in libusb is because SetupAPI falls short, and does not cache/provide the information it should provide in the first place (because it asserts that people should only deal with "abstract devices"). So we have to issue icotls to hubs just to retrieve USB device descriptors that by all means the OS should make available to us, from a cached version established when the device was first detected (caching which I believe you _had_ to implement in the 0 and K drivers because, even as the retrieval of descriptor is something so generic that an OS should be able to perform it on its own, Windows couldn't help you there). If you think I'm issuing ioctl's in libusb because I saw it as the easy way out, you're wrong. The last thing I want is query the hubs. But using SetupAPI and not being able to force the OS to relinquish information it has (or should have) regarding the devices plugged in leaves no other alternative. Bonus question: Say libusbK wants to support a driver which you don't control the source of, and which doesn't provide an API to cached descriptors, and you want to build an enum that provides said descriptors - how do you proceed? > I think the good idea is to have a device list that gives you a vid, > pid, and a serial-number/unique ID; product and mfu strings would be a > bonus. That's really all you need at the "list" stage. If it's USB, some descriptors at enum time would be nice too, especially as a proper OS would read them on device detection and make a cached copy available through an API. > Windows can do > this with no extra I/O no problem; as many times as you want it. Yes I know.Still doesn't solve the descriptors issue. > I'm > trying to figure out how to get linux-libusb-1.0 to give all this info > up without extra I/O, but it seems it cannot do it. Then it's a caching issue with the OS. I thought usbfs was doing that, because it seems like the obvious thing to do to me, but I haven't looked at the usbfs implementation. Regards, /Pete |