Re: [Libusbx-devel] [RFC] Windows event handling improvements
Hi, On 04/11/2013 05:20 PM, Toby Gray wrote: > Hi, > > We've been looking into the performance of the Windows desktop and Windows CE > versions of libusbx compared to Linux on the same hardware. The event > handling in Windows and Windows CE appears to take considerably longer than > for Linux. > > This is understandable given the way that the windows backends need to > pretend to have fds for the core of libusbx to process. > > Rather than trying to optimise how the fake fds are generated and handled, I > think the best thing to do is to add improved APIs to improve event handling > on platforms which don't have fds and then change the internals to not need > fake fds. > > Before I rush off an implement something, I wanted to check with the > community to see how people feel things should be done. > > I see two possible ways of approaching the problem: > > 1) Add a new type, libusb_event_handle, which either maps to an FD or a > HANDLE, as appropriate on each platform. I've attached a first attempt at the > API changes in new_event_api.diff. It is a new API but is very similar to the > pre-existing poll api. > > 2) Add the ability to start and stop async event processing threads which are > internal to libusb. I've attached a first attempt at the API changes in > async_thread_api.diff. > > I think the second approach probably matches up better with the future > direction of hotplug. The only benefit I can really think of the former > approach is that it allows the libusbx user to continue to control the thread > context for transfer completion callbacks, as well as when the callbacks can > occur. I don't want to come over to negative here, but I'm strongly against method 2. Many applications and frameworks still follow the model of having a single main event loop. 1) fits this very nicely where as 2) does not at all. 2) Can be easily offered on top of 1 by having a start / stop event handling functions, which start a thread and then fire of callbacks from that thread for API users who don't mind dealing with threading issues, and don't want to be bothered with calling some wait-for-events function themselves. As for 2 matching with hotplug, the latest (not saying it is the best, but it is the most concrete code we've atm) hotplug code in the libusb-1.0.16 rc-s has been changed to no longer fire hotplug events from $random-thread, instead they are now fired from which ever thread calls libusb_handle_events*, and there is an fd to poll to figure out when calling libusb_handle_events* for hotplug is necessary. So the libusb-1.0.16rc hotplug code currently behaves much more like 1) then like 2) Also as Pete said, lets not spend too much time talking about this, just show us the code :). Preferably code modeled after method 1). Regards, Hans -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Storing debug database for prebuilt binaries
On 11/04/13 22:44, Pete Batard wrote: On 2013.04.11 12:18, Toby Gray wrote: I will modify the bwince.cmd that I send previously Ah sorry, I completely missed that one, along with your SF id. You should now have the rights to upload and modify files in the SourceForge download area. That worked, thanks. I've uploaded WinCE binaries built from RC3 (so they don't include any changes since the rc3 tag). I'll add updated binaries when you tag each RC. I also applied your earlier WinCE build related patches, along with the .pdb corrective. They have now been pushed to mainline. Excellent. I've just realised that the binary snapshots don't contain any licensing information within them. I've attached a patch which makes the license clear in the README.txt and includes COPYING. Regards, Toby >From 6a1410c964762dc17b76326be0c00a32d4e05ea8 Mon Sep 17 00:00:00 2001 From: Toby Gray Date: Fri, 12 Apr 2013 15:42:38 +0100 Subject: [PATCH] Windows: Include COPYING and license information in binary snapshots. --- .private/bd.cmd|1 + .private/bwince.cmd|1 + .private/wbs.txt |5 + .private/wbs_wince.txt |5 + 4 files changed, 12 insertions(+), 0 deletions(-) diff --git a/.private/bd.cmd b/.private/bd.cmd index d02ce23..5c275d8 100644 --- a/.private/bd.cmd +++ b/.private/bd.cmd @@ -17,6 +17,7 @@ copy examples\ezusb.? E:\dailies\%DATE%\examples\source copy examples\fxload.c E:\dailies\%DATE%\examples\source copy msvc\stdint.h E:\dailies\%DATE%\examples\source copy .private\wbs.txt E:\dailies\%DATE%\README.txt +copy COPYING E:\dailies\%DATE%\COPYING set ORG_BUILD_ALT_DIR=%BUILD_ALT_DIR% set ORG_BUILDARCH=%_BUILDARCH% diff --git a/.private/bwince.cmd b/.private/bwince.cmd index 555e3b2..91a0b2f 100755 --- a/.private/bwince.cmd +++ b/.private/bwince.cmd @@ -33,6 +33,7 @@ copy examples\listdevs.c %WINCE_TARGET_DIR%\examples\source copy examples\xusb.c %WINCE_TARGET_DIR%\examples\source copy msvc\stdint.h %WINCE_TARGET_DIR%\examples\source copy .private\wbs_wince.txt %WINCE_TARGET_DIR%\README.txt +copy COPYING %WINCE_TARGET_DIR%\COPYING rem Perform the rebuild for %%A in (%WINCE_TARGET_ARCHES%) do %MSBUILD_CMD% %WINCE_SLN% /property:Platform="%PLATFORM_PREFIX%%%A%PLATFORM_POSTFIX%" /property:Configuration=%MSBUILD_CONFIGURATION% /target:%MSBUILD_TARGET%" diff --git a/.private/wbs.txt b/.private/wbs.txt index 2e2d9d8..0597ec5 100644 --- a/.private/wbs.txt +++ b/.private/wbs.txt @@ -5,6 +5,11 @@ * https://sourceforge.net/projects/libusbx/files/ * * +The binaries contained in this snapshot are licensed under the +GNU Lesser General Public License version 2.1 or, at your option, any later +version (see COPYING for further details). The source code for these binaries +is available for download at the same location as this binary snapshot. + o Visual Studio: - Open existing or create a new project for your application - Copy libusb.h, from the include\libusbx-1.0\ directory, into your project and diff --git a/.private/wbs_wince.txt b/.private/wbs_wince.txt index b835eea..ebd890d 100755 --- a/.private/wbs_wince.txt +++ b/.private/wbs_wince.txt @@ -5,6 +5,11 @@ * https://sourceforge.net/projects/libusbx/files/ * * +The binaries contained in this snapshot are licensed under the +GNU Lesser General Public License version 2.1 or, at your option, any later +version (see COPYING for further details). The source code for these binaries +is available for download at the same location as this binary snapshot. + o Visual Studio: - Open existing or create a new project for your application - Copy libusb.h, from the include\libusbx-1.0\ directory, into your project and -- 1.7.9 -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC] Windows event handling improvements
On 11/04/13 18:17, Tim Roberts wrote: > Toby Gray wrote: >> We've been looking into the performance of the Windows desktop and >> Windows CE versions of libusbx compared to Linux on the same hardware. >> The event handling in Windows and Windows CE appears to take >> considerably longer than for Linux. >> >> This is understandable given the way that the windows backends need to >> pretend to have fds for the core of libusbx to process. > Can you share with the performance numbers you have and a short > description of how you got them? You've made me really curious here. > Intuitively, I would have guessed that whatever fd futzing was going on > was absolutely insignificant when compared to the overhead of > user/kernel transitions and user event processing. > The only numbers which would probably make sense to others are that we noticed that there was a long time between the short packet of the end of a transfer and the host issuing the next IN token for that endpoint. The gap is multiple milliseconds in length on WinCE, but not when the same board is running a Linux image. We have finally got around to making sure that we have multiple concurrent bulk in transfers to eliminate this latency. I know that we should have been doing this from the start, but higher priority things had always got in the way and the event handling in Linux was fast enough for us to get away with it. So it's now a case of reducing the CPU time that we see in the processing of events. We've not drilled down fair enough yet to discover exactly where the time goes. When I do get time to create a working patch series I'll be sure to include meaningful figures from benchmarks which others will be able to reproduce. I appreciate that without this information it would just be large code churn with no way of gauging how much it helps. Regards, Toby -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
using libusbx-1.0.14 and libftdi (the problem is similar with 1.0.15-rc3) downloaded from http://mcuee.blogspot.fr/ (Xiaofan's blog _ the devKit) here's a report of a user that run Vista 32bits C:\users\...\bin>find_all.exe Number of FTDI devices found: 1 Checking device: 0 ftdi_usb_get_strings failed: -4 (libusb_open() failed) on a Win7 box, the same find_all.exe successfully find the same device. Hope you'll be able to fix that. best regards, Nicolas Le 11/04/13 15:47, Xiaofan Chen a écrit : On Thu, Apr 11, 2013 at 9:30 PM, nico wrote: Hi, is there is any windows Vista32 restriction? No, libusbx should work under Vista 32 bit or 64bit. Actually it works under Windows XP x86, Vista x86/x64, Win7 x86/x64 and Windows 8 x86/x64. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC] Windows event handling improvements
Hi, On 12/04/13 12:49, Hans de Goede wrote: > > On 04/11/2013 05:20 PM, Toby Gray wrote: >> >> I see two possible ways of approaching the problem: >> >> 1) Add a new type, libusb_event_handle, which either maps to an FD or >> a HANDLE, as appropriate on each platform. I've attached a first >> attempt at the API changes in new_event_api.diff. It is a new API but >> is very similar to the pre-existing poll api. >> >> 2) Add the ability to start and stop async event processing threads >> which are internal to libusb. I've attached a first attempt at the >> API changes in async_thread_api.diff. >> >> I think the second approach probably matches up better with the >> future direction of hotplug. The only benefit I can really think of >> the former approach is that it allows the libusbx user to continue to >> control the thread context for transfer completion callbacks, as well >> as when the callbacks can occur. > > I don't want to come over to negative here, but I'm strongly against > method 2. Thank you for your feedback. I think I'll give approach 1 a go as the first attempt. There will need to be a per platform event handle abstraction for either method, it's just whether it's in libusb.h or libusbi.h, which is easily modifiable once people can see what all the other changes to the os/*.c code. > Also as Pete said, lets not spend too much time talking about this, > just show us > the code :). Preferably code modeled after method 1). Will do. It might be a couple of months what with wanting to test that I've not broken any of the backends and that it does actually improve performance. Regards, Toby -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC] Windows event handling improvements
On 12/04/13 00:27, Pete Batard wrote: > On 2013.04.11 16:20, Toby Gray wrote: >> Rather than trying to optimise how the fake fds are generated and >> handled, I think the best thing to do is to add improved APIs to improve >> event handling on platforms which don't have fds and then change the >> internals to not need fake fds. > Oh boy, here we go again... Sorry, I didn't realise it was a common discussion point. I was trying to avoid doing what I did with the WinCE backend of going ahead and implementing something and only talking to the community when it was done. I think the summary from all the replies seems to be: * any changes to event handling will not be considered for merging until after hotplug is done (at least 10 months time) * any work on event handling is likely to be unusable once hotplug starts to be implemented (as it is likely to also modify event handling code) * if I'm contributing time to libusbx development that it would be more useful if it was working on hotplug (or other features in the next milestone) * don't send apis, send working code :) >> Before I rush off an implement something, I wanted to check with the >> community to see how people feel things should be done. > If that's the case, then you may want to check 3 years of libusb mailing > list archives as well as one year of libusbx, because this topic has > probably been discussed about once every 3 months on each list. > > I think the plan on which we more or less agreed for libusbx was that we > would wait until _AFTER_ we had an initial hotplug implementation for > all of Linux, OS X and Windows, to look into improved event handling. > > The reason is it'd be nice if the hotplug event handling could fit with > the transfer event handling, but until we see clearer in terms of > hotplug, whatever we _think_ we need in terms of event handling may end > up being way off mark. > > Also see the current v2.3 libusbx milestone: > https://github.com/libusbx/libusbx/issues/milestones > > IMO this is still way off on the horizon, and isn't something we should > be looking at right now, especially not in the 1.x branch. All of which are very understandable and good reasons. I am still (pleasantly) surprised that the WinCE backend was integrated so quickly. I was expecting at least a year of maintaining it in a branch until a suitable milestone came up. I have the same, original, expectations of needing to maintain a branch for 12+ months for any patches that I come up with for improving the event handling performance. > OK, then let me be very frank here (with an opinion that'll probably not > reflect the one from other libusbx maintainers): I'm getting kind of > tired of people proposing yet another API, without any details of how > it's actually going to be implemented for each of our 3 major platforms > (Linux + OS X + Windows). And yeah, I know RFC and whatnot may sound > like the way to go, but proposing an API _is_ cheap, and, judging from > our mailing list history, seems to be a sure way to generate a lot of > discussion that ends up nowhere or worse, that detracts people from what > our real number one need which is: code, code, and more code. Frankness is good and gets across the point. Unless some else posts something that I feel I really need to reply to, I don't plan on sending any more traffic to the mailing list about this until I have a working implementation (for all backends) with useful performance figures. I especially appreciate that you've taken the time to write a long reply, but that the time you spent writing the reply could have been spent making libusbx more awesome. > So if it were up to me, I'd try to concretely find out what we really > need (which, unfortunately, requires a somewhat working Windows hotplug > implementation) before trying to introduce improved event handling... To return your frankness: the majority of my time spent on libusbx is as part of my day job. That means that it is difficult to justify using company time to implement features that aren't of any direct use to the company. The libusbx activity I can do when not at work is limited by lack of non-free development tools and environments at home. We are happy to accept that our requirements won't match up exactly with the requirements of the libusbx community and so we might need to maintain a branch of libusbx with bug fixes and functionality that we need for months, if not forever (but hopefully not). In this case though I've clearly let the community know a bit too early and wasted everyone's time. As I mentioned above I'll wait until I've got working code with a measurable benefit before bringing this subject up on the list again. Regards, Toby -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal to
Re: [Libusbx-devel] [RFC] Windows event handling improvements
Toby Gray wrote: > The only numbers which would probably make sense to others are that we > noticed that there was a long time between the short packet of the end > of a transfer and the host issuing the next IN token for that endpoint. > The gap is multiple milliseconds in length on WinCE, but not when the > same board is running a Linux image. There must be about a dozen causes behind that, and Libusbx's event handling has to be about #11 on that list in terms of importance. My guess is that the #1 cause is the design of the USB host controller driver. The WinCE USB stack is primitive. It hasn't received anywhere NEAR the attention or the real-world stress testing that either the Windows or the Linux USB stack has had. I suspect, for example, that it only asks for an interrupt at end of frame, and it submits the next frame's schedule immediately. In that case, unless you have multiple concurrent requests, you will NEVER get more than one request every two milliseconds. It's impossible, and there is nothing you can do in user-mode code to fix that. > We have finally got around to making sure that we have multiple > concurrent bulk in transfers to eliminate this latency. I know that we > should have been doing this from the start, but higher priority things > had always got in the way and the event handling in Linux was fast > enough for us to get away with it. Sometimes. Even when it works, it's very delicate, and highly dependent on system load. It wouldn't take an awful lot of competing CPU activity to make it break on Linux as well. The ONLY robust solution is multiple pending requests. > So it's now a case of reducing the CPU time that we see in the > processing of events. We've not drilled down fair enough yet to discover > exactly where the time goes. You are free to chase this line of investigation if you want, of course, but it is my educated opinion that you are wasting your time. You are solving a problem that simply cannot be solved in the general case. You are bucking Amdahl's Law here. The libusbx event handling is such a small part of the problem that, even if you completely eliminated all of the libusbx overhead, you would have improved the overall performance so slightly that it makes no difference. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On Fri, Apr 12, 2013 at 11:06 PM, nico wrote: > using libusbx-1.0.14 and libftdi (the problem is similar with 1.0.15-rc3) > downloaded from http://mcuee.blogspot.fr/ (Xiaofan's blog _ the devKit) > here's a report of a user that run Vista 32bits > C:\users\...\bin>find_all.exe > Number of FTDI devices found: 1 > Checking device: 0 > ftdi_usb_get_strings failed: -4 (libusb_open() failed) > > on a Win7 box, the same find_all.exe successfully find the same device. > Hope you'll be able to fix that. You should use the 1.0.15rc3 since 1.0.14 has potential problem with USB composite device. How do you install the driver under the Vista 32bit system and the Win7 system? And you may want to post the debug log to see what is the problem. You can set LIBUSB_DEBUG=4 and then run the find_all.exe to get the debug log. -- Xiaofan -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC] Windows event handling improvements
On Sat, Apr 13, 2013 at 12:14 AM, Toby Gray wrote: > Sorry, I didn't realise it was a common discussion point. I was trying > to avoid doing what I did with the WinCE backend of going ahead and > implementing something and only talking to the community when it > was done. Yes I think this is a good move. > I think the summary from all the replies seems to be: > * any changes to event handling will not be considered for merging until > after hotplug is done (at least 10 months time) The 10 months time is an estimate. If there are more contributors from the community (like you), it could be faster. We can also shuffle the milestones depending on the request of the community. Right now hotplug seems to have the highest demand, so it is in Milestone 2.1. If the event handling is next in line, we can make it Milestone 2.2. And personally I think event handling is also very high on the demand based on past discussions. If you look at the current Milestone 2.2, #15 is the only one relatively important feature but it could be a minor effort since we can potentially leverage the commit by Nathan in libusb-darwin. The other two are just minor. So we could just combine Milestone 2.2 and 2.3 to make it Milestone 2.2. > * any work on event handling is likely to be unusable once hotplug > starts to be implemented (as it is likely to also modify event handling > code) This may or may not be true depending on how hotplug is implemented. > * if I'm contributing time to libusbx development that it would be more > useful if it was working on hotplug (or other features in the next > milestone) Since hotplug could potentially affect the event handling part, it is better to work on hotplug first. But you can also work on future milestone items if it is kind of independent to other features, eg, the USB 3.0 descriptor parsing. > * don't send apis, send working code :) Not really true. I think both are needed. Usually the API proposals come first. On the other hand, API proposals need to consider the potential implementation hurdles at least in the three major platforms (Linux, Mac OS X and Windows). -- Xiaofan -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On Sat, Apr 13, 2013 at 11:40 AM, Xiaofan Chen wrote:
> On Fri, Apr 12, 2013 at 11:06 PM, nico wrote:
>> using libusbx-1.0.14 and libftdi (the problem is similar with 1.0.15-rc3)
>> downloaded from http://mcuee.blogspot.fr/ (Xiaofan's blog _ the devKit)
>> here's a report of a user that run Vista 32bits
>> C:\users\...\bin>find_all.exe
>> Number of FTDI devices found: 1
>> Checking device: 0
>> ftdi_usb_get_strings failed: -4 (libusb_open() failed)
>>
>> on a Win7 box, the same find_all.exe successfully find the same device.
>> Hope you'll be able to fix that.
>
> You should use the 1.0.15rc3 since 1.0.14 has potential problem
> with USB composite device.
>
> How do you install the driver under the Vista 32bit system and
> the Win7 system?
>
> And you may want to post the debug log to see what is the problem.
> You can set LIBUSB_DEBUG=4 and then run the find_all.exe to get
> the debug log.
In any case, I just tested under Windows Vista x64 64bit system and
the libftdi1-1.0 binary works fine with either libusbx 1.0.14 dll or the
libusbx 1.0.15rc3 dll.
For example, this is the debug log with 1.0.15rc3 dll.
C:\work\libftdi\libftdi1-1.0_devkit_mingw32_17Feb2013\bin>find_all.exe
Number of FTDI devices found: 1
Checking device: 0
Manufacturer: FTDI, Description: FT232R USB UART
C:\work\libftdi\libftdi1-1.0_devkit_mingw32_17Feb2013\bin>set LIBUSB_DEBUG=4
C:\work\libftdi\libftdi1-1.0_devkit_mingw32_17Feb2013\bin>find_all.exe
[timestamp] [threadID] facility level [function call]
[ 0.00] [07e0] libusbx: debug [libusb_init] created default context
[ 0.00] [07e0] libusbx: debug [libusb_init] libusbx v1.0.15.10641
[ 0.00] [07e0] libusbx: debug [setup_cancel_io] Will use CancelIoEx for
I/O cancellation
[ 0.00] [07e0] libusbx: debug [winusbx_init] using libusbK DLL for unive
rsal access
[ 0.00] [07e0] libusbx: debug [winusbx_init] libusbK version: 3.0.5.16
[ 0.00] [07e0] libusbx: debug [winusbx_init] initalized sub API libusbK
[ 0.00] [07e0] libusbx: debug [winusbx_init] initalized sub API libusb0
[ 0.00] [07e0] libusbx: debug [winusbx_init] initalized sub API WinUSB
[ 0.00] [07e0] libusbx: debug [htab_create] using 1021 entries hash tabl
e
[ 0.00] [07e0] libusbx: debug [usbi_add_pollfd] add fd 0 events 1
[ 0.00] [07e0] libusbx: debug [libusb_get_device_list]
[ 0.015625] [07e0] libusbx: debug [windows_get_device_list] allocating new d
evice for session [20F]
[ 0.015625] [07e0] libusbx: debug [windows_get_device_list] allocating new d
evice for session [38D]
[ 0.015625] [07e0] libusbx: debug [get_api_type] driver(s): usbhub
[ 0.015625] [07e0] libusbx: debug [get_api_type] matched driver name against
HUB API API
[ 0.015625] [07e0] libusbx: debug [windows_get_device_list] allocating new d
evice for session [2C9]
[ 0.015625] [07e0] libusbx: debug [get_api_type] driver(s): usbhub
[ 0.015625] [07e0] libusbx: debug [get_api_type] matched driver name against
HUB API API
[ 0.015625] [07e0] libusbx: debug [windows_get_device_list] allocating new d
evice for session [E4]
[ 0.015625] [07e0] libusbx: debug [windows_get_device_list] found existing d
evice for session [2C9] (0.0)
[ 0.015625] [07e0] libusbx: debug [init_device] (bus: 1, addr: 1, depth: 0,
port: 0): '\\.\USB#ROOT_HUB#4&24D6EB65&0'
[ 0.015625] [07e0] libusbx: debug [windows_get_device_list] found existing d
evice for session [E4] (0.0)
[ 0.015625] [07e0] libusbx: debug [init_device] (bus: 2, addr: 1, depth: 0,
port: 0): '\\.\USB#ROOT_HUB20#4&6A987E4&0'
[ 0.015625] [07e0] libusbx: debug [windows_get_device_list] extra GUID: {283
9D1A7-13FE-4E1D-AE0E-27B87039D69D}
[ 0.015625] [07e0] libusbx: debug [windows_get_device_list] allocating new d
evice for session [1DE]
[ 0.031250] [07e0] libusbx: debug [init_device] found 1 configurations (acti
ve conf: 1)
[ 0.031250] [0f88] libusbx: debug [windows_clock_gettime_threaded] hires tim
er available (Frequency: 3579545 Hz)
[ 0.046875] [07e0] libusbx: debug [cache_config_descriptors] cached config d
escriptor 0 (bConfigurationValue=1, 32 bytes)
[ 0.046875] [07e0] libusbx: debug [init_device] (bus: 1, addr: 4, depth: 1,
port: 3): '\\.\USB#VID_0403&PID_6001#A8007UB5'
[ 0.046875] [07e0] libusbx: debug [windows_get_device_list] allocating new d
evice for session [2A1]
[ 0.046875] [07e0] libusbx: debug [init_device] found 1 configurations (acti
ve conf: 1)
[ 0.062500] [07e0] libusbx: debug [cache_config_descriptors] cached config d
escriptor 0 (bConfigurationValue=1, 55 bytes)
[ 0.062500] [07e0] libusbx: debug [init_device] (bus: 2, addr: 2, depth: 1,
port: 1): '\\.\USB#VID_0403&PID_CFF8#53T9XDR4'
[ 0.062500] [07e0] libusbx: debug [windows_get_device_list] extra GUID: {F73
DE082-EDE0-4CDB-AB74-09DB4E5A2CB3}
[ 0.078125] [07e0] libusbx: debug [windows_get_device_list]
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
Hi Le 13/04/13 05:40, Xiaofan Chen a écrit : > On Fri, Apr 12, 2013 at 11:06 PM, nico wrote: >> using libusbx-1.0.14 and libftdi (the problem is similar with 1.0.15-rc3) >> downloaded from http://mcuee.blogspot.fr/ (Xiaofan's blog _ the devKit) >> here's a report of a user that run Vista 32bits >> C:\users\...\bin>find_all.exe >> Number of FTDI devices found: 1 >> Checking device: 0 >> ftdi_usb_get_strings failed: -4 (libusb_open() failed) >> >> on a Win7 box, the same find_all.exe successfully find the same device. >> Hope you'll be able to fix that. > You should use the 1.0.15rc3 since 1.0.14 has potential problem > with USB composite device. the user have tried with the 15rc3 with the same result (the device is a 0x0403, 0x6001) > > How do you install the driver under the Vista 32bit system and > the Win7 system? we use zadig (the last one) to install the WINUSB drivers > > And you may want to post the debug log to see what is the problem. > You can set LIBUSB_DEBUG=4 and then run the find_all.exe to get > the debug log. can you please provide a mingw32 dll with the LIBUSB_DEBUG flag (in case I do something wrong at compilation stage...). like that I can send it to try. best regards, Nicolas -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
