Re: [Libusbx-devel] libusbx: error [cache_config_descriptors] could not access configuration descriptor
On 2014.09.03 09:35, Qian Peng wrote: libusbx: error Looks like you are using libusbx, which has been superseded by libusb. Can you try with the latest libusb (Please visit http://libusb.info), in case it fixed that issue. the issue looks like http://sourceforge.net/p/libusbx/mailman/libusbx-devel/thread/1349577786.68914.1354005550176.JavaMail.open-xchange%40com4.strato.de/#msg30149384 How do we avoid or solve the problem? As advised in the thread you point out, you may want to have a look at what USBView reports. Also, the device you are trying to access appears to be a Kingston DataTraveler 2.0 Stick (2GB) (http://www.linux-usb.org/usb.ids - 0930:6544), which is a mass storage device. Can you clarify why you are trying to access a regular mass storage device using libusb on Windows? This means having to replace the default Mass Storage driver with WinUSB and losing native access to device as a flash drive, which seems like an odd thing to try to do... Regards, /Pete -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)
Hi Chris, No objection from me. ;) You've been around our lists long enough, have been doing plenty of good work already, and crucially, you indicate that you have some time for it, so if you want the Windows maintainer job, since I'm pretty sure other maintainers will feel the same way I do, consider it yours! I have now added you to the list of github maintainers for the project, and if you send one of us your SourceForge username, we can also add you to the project there (which is required for file uploads, etc.) I should also point out that, I'm not planning to drop off the libusb map altogether, so I'll continue to try to help where I can (feel free to drop me an e-mail anytime). Of course, you have my thanks for volunteering to take the Windows maintenance over! Regards, /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/9#issuecomment-48125032-- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Announce libusb-1.0.19-rc1
Windows binaries of 1.0.19-rc1 (+2) have also been uploaded. +2, as it includes the 2 minor commits we have on top of RC1, including a WDK fix that was needed to build the binaries. Available, along with the RC1 source tarball from: https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.19/ Regards, /Pete -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Windows 8: Incorrect USB 3.0 speed detection (#155)
This has now been fixed in libusb in https://github.com/libusb/libusb/commit/d41802053c4f20691f38072879c9dd76806f0f91. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/155#issuecomment-43448732-- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Fixed incorrect error message in fxload. (#169)
This was fixed in libusb. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/169#issuecomment-43448797-- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Fixed incorrect error message in fxload. (#169)
Closed #169. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/169#event-122265408-- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] Fwd: [Libusb-win32-devel] Donation for a new Kernel Mode Code Signing Certificate
Since libusb on Windows supports the use of the libusbK libusb-win32 drivers, which is what the code signing certificate below is all about, I think this request should also be forwarded to the list. It would be nice to have enough donations to purchase a 3 year certificate, so that we don't have to worry about this for a while. /Pete Original Message Subject: [Libusb-win32-devel] Donation for a new Kernel Mode Code Signing Certificate Date: Thu, 10 Apr 2014 09:03:51 +0800 From: Xiaofan Chen xiaof...@gmail.com Reply-To: libusb-win32-de...@lists.sourceforge.net To: libusb-win32-de...@lists.sourceforge.net 3 years back, we had a successful donation drive. http://libusb.6.n5.nabble.com/A-final-thanks-for-the-contributions-td3929270.html Now it is time to get another Kernel Mode Code Signing Certificate. Donation link (to Travis) http://sourceforge.net/donate/?user_id=1850769 Since June 1, 2013 GlobalSign will no longer be offering Code Signing Certificates for Individuals. So we need to get a different certificate this time. Possible code signing vendors: http://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx One possibility: https://www.globalsign.com/code-signing/ US$229 for 1 year US$422 for 2 years US$563 for 3 years -- Xiaofan -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Libusb-win32-devel mailing list libusb-win32-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] build error: undefined reference to `libusb_error_name'
Hi Carl, On 2014.04.06 17:00, Carl Karsten wrote: Does anyone know if the current fxload is in a debian repo or PPA? All I can tell you, is what the initial commit for fxload reports [1]: * This program was modified from the original fxload at: http://linux-hotplug.sourceforge.net to add libusb as well as non HEX images support. I think this is the project Debian use as their base, but the original project's fxload doesn't seem to have been updated for some time. but in the changelog: * renamed to fxload from hotplug-utils fxload.c was originally main.c in the linux-hotplug project. Regards, /Pete PS: Your patch has now been applied into the libusb repository [1] https://github.com/libusb/libusb/commit/05975333c53d58a98b1e91f1edd220d794c7dd46 -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] refresher ...
Hi, On 2014.02.18 13:39, g...@novadsp.com wrote: Looks like there have been some changes to the project(s) recently. Can anyone tell me which repo/site/newslist are now the masters for libusb-x? Copied from the orignal libusb 1.0.18 announcement IF YOU ARE AN EXISTING LIBUSBX USER: - The SourceForge project changes from https://sourceforge.net/projects/libusbx/ to https://sourceforge.net/projects/libusb/ - The mailing list changes from libusbx-devel@lists.sourceforge.net to libusb-de...@lists.sourceforge.net - The API documentation changes from at: http://libusbx.sourceforge.net/api-1.0/ to http://libusb.sourceforge.net/api-1.0/ - The git repository changes from git://github.com/libusbx/libusbx.git to git://github.com/libusb/libusb.git - The Homepage changes from http://libusbx.org to http://libusb.info - The github project (Wiki, issue tracker, etc.) changes from https://github.com/libusbx/libusbx to https://github.com/libusb/libusb http://libusb.info also has these accessible from the various menus on the page. Regards, /Pete -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: ASMedia XHCI enumeration issues. (#147)
Initial testing of your patch indicates that this seems to fail for both composite and driverless devices. Composite seems to be due to not processing the usbccgpp, but its children, and driverless seems to be due to driverless devices not providing a software key/driver key in the first place (which indeed is confirmed by our existing message `The following device has no driver, libusb will not be able to access it`, which is only triggered if the driver key was not found)... /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/147#issuecomment-34943935-- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: ASMedia XHCI enumeration issues. (#147)
Thanks for reminding me. I'll try to look at it soon...ish. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/147#issuecomment-34236278-- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Announcing libusb-1.0.18 (as well as libusbx-1.0.18 *FINAL*)
On 2014.01.27 12:46, Erik Rull wrote: I would just like to know what could be the reason why or what is going wrong. I just see the effect, but I'm not an expert in the USB interiors, otherwise the patch would have been provided already :-) I wasn't asking for you to provide a patch. That's still the job of maintainers and contributors. Right now, everybody seems a bit squeezed to investigate your issue, but we'll try to make time for it when we get a chance. Regards, /Pete -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Fix mingw parallel build (#168)
Closed #168 via fc458425b6dd6258e562e44c22978ab22412ff0a. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/168-- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] Announcing libusb-1.0.18 (as well as libusbx-1.0.18 *FINAL*)
Hi, It is my great pleasure to announce the release of libusb 1.0.18 (as well as the simultaneous final release of libusbx 1.0.18), which marks the long awaited merging back of libusbx with libusb! With this release, we are finally consolidating the two projects back into one, and bringing the many bug fixes and new features of libusbx, into libusb, for the benefit of all. For all programming purposes, you should consider that these simultaneous 1.0.18 releases are essentially the same. The only difference between them is that a bunch of strings, which bear no impact on either the compilation or the API (95% of them being in comments) say libusbx on one side and libusb on the other. Outside of that the code is identical and the name of the header, library and API function calls, which were already the same to begin with, are still identical in both libraries, with the libraries themselves still being interchangeable. We therefore strongly encourage you to move to using libusb 1.0.18 in your project(s) as soon as possible, especially as all future libusb related development will occur from the single libusb project. You can find the libusb 1.0.18 release tarball at: https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.18/ With regards to the changes pertaining to this release, because the list would be too long to copy/paste, as there hasn't been any official libusb release since version 1.0.9, you can obtain the full ChangeLog by going to: http://log.libusb.info With this release however, we had to make some adjustments to our URLs (mostly because the person in charge of the original domain wasn't interested in helping the project move forward), so please take note of the following: * IF YOU ARE AN EXISTING LIBUSB USER: - The SourceForge project remains at https://sourceforge.net/projects/libusb/ - The mailing list remains at libusbx-devel@lists.sourceforge.net - The API documentation remains at: http://libusb.sourceforge.net/api-1.0/ - The git repository changes from git://git.libusb.org/libusb.git to git://github.com/libusb/libusb.git - The Homepage changes from http://libusb.org to http://libusb.info - The Wiki and issue tracker are change to github at https://github.com/libusb/libusb * IF YOU ARE AN EXISTING LIBUSBX USER: - The SourceForge project changes from https://sourceforge.net/projects/libusbx/ to https://sourceforge.net/projects/libusb/ - The mailing list changes from libusbx-devel@lists.sourceforge.net to libusb-de...@lists.sourceforge.net - The API documentation changes from at: http://libusbx.sourceforge.net/api-1.0/ to http://libusb.sourceforge.net/api-1.0/ - The git repository changes from git://github.com/libusbx/libusbx.git to git://github.com/libusb/libusb.git - The Homepage changes from http://libusbx.org to http://libusb.info - The github project (Wiki, issue tracker, etc.) changes from https://github.com/libusbx/libusbx to https://github.com/libusb/libusb Please make sure you update your tracking of the project as required. Obviously, we would have preferred avoiding the domain change (but we would still have moved the git repository, issue tracker and Wiki to github, as it's more convenient) and while we understand that moving from .org to .info may create some temporary confusion, we hope that, as everyone starts to reference http://libusb.info as the new home of the libusb project, this confusion will be as short lived as possible. You are invited to visit http://libusb.info, which contains all the links that are mentioned above, as well as additional information. Thank you, /Pete -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Don't skip initialisation on known devices.
On 2014.01.23 19:43, Bent Bisballe Nyeng wrote: On 01/23/14 20:13, Tim Roberts wrote: Bent Bisballe Nyeng wrote: We have a composite device that works like a USB HUB connecting to one device at a time. When a new connection is made the endpoints change although the device connection itself is not changed. What led you to think that was a legitimate thing to do? Once a driver has done a set configuration, it's not clear that the endpoint configuration is allowed to change. You can certainly have multiple alternate settings, where each setting has a different set of endpoints, but I don't see how you can possibly expect an on-the-fly change to work. How would you notify the host that things have changed? You can't expect it to poll your descriptors repeatedly. Allow me to elaborate a bit; we did not /make/ the device, we are merely /using/ it and need it to work. I do not know whether the behavior is embraced by the USB specification, all I'm saying is, that it did work with libusb once, and the patch made it work again I'm with Tim on this, and I will even go further than that. Anything that is not explicitly specified in the USB specs is left to the implementer's choice, and the general libusb direction is to probe and update a device's parameters as little as we possibly can. You say your device works like a HUB. Does it trigger a device removal insertion notification from the OS when a new connection is made? If not, then I have to ask what you are planning to do once libusb follows through with what we ultimately want to do with regards to hoptplug, which would be to only update our internal USB device tree on device insertion/removal. Unless your device acts as if a removal took place when it switches connection then, you'll probably find that even if we were to revert this section, a future version of libusb would likely break that behaviour again... The only reason it used to work is that the current Windows implementation has no hotplug awareness, so we enumerate the whole USB tree, including the device's property, every time a device is opened. Of course, this is less than optimal, so when we have means to make that process slightly faster (with the code you want to see removed for instance), we will add it, until, eventually, we might be able to enumerate the whole bus once per session, and only update our tree on a single device basis, as they are removed or inserted. Overall, you may have been lucky, and got to use a version of libusb that unintentionally happened to provide the feature you wanted to rely on. But we can make no promise of backwards compatibility on such accidental features, especially as our plan is to go in the opposite direction. Thus I don't think we want to revert this code. Instead, I would advise to try to factor out luck or reliance on a behaviour that the USB specifications leave unclear, even as it may require a greater effort from your side. Oh, and I'm also curious as to how your device is meant to behave on other OSes, such as Linux or OS X, especially when using the latest libusb. Do you see the endpoint update there? Regards, /Pete PS: I'm currently planning to delay the 1.0.18 release for a couple more days (current estimate = Saturday or Sunday), as we're still waiting on Nathan's feedback and I could use the time on a couple non libusb things. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Announcing libusb-1.0.18-rc1
On 2014.01.09 06:30, Bent Bisballe Nyeng wrote: How much difference will there be to libusbx-1.0.18 and libusb-1.0.18? As far as developers are concerned, no difference. What I mean is; will the merge simply be a copy of the current libusbx code to the libusb repository Yup. Just one extra commit was added, that basically changes a bunch of libusbx strings back to libusb. And since no libusbx string was ever used as part of the API call, outside of LIBUSBX_API_VERSION, for which we have a workaround (#define LIBUSBX_API_VERSION LIBUSB_API_VERSION), you can just drop a library in place of the other, and, as long as it was compiled with the same options, it will work (or fail) in the exact same manner. or are there still parts of libusb code left that were otherwise changed in the libusbx project? Nope. The functionality is exactly the same. There's no feature or bugfix in one has the other doesn't replicate exactly. If you check the git repositories for both libraries, this should also be fairly obvious. I'm also going to duplicate part of the libusbx announcement that went to this very list right before the announcement you are replying to, and that tried to explain that the libraries are virtually identical: As far as the code is concerned, the current libusb repository and the current libusbx repository can be considered identical, and of course the libraries are fully interchangeable, up to the latest libusbx features and bug fixes. The only difference between the library stands in one commit, that updates most of the comments and documentation that was referencing libusbx, into referencing the updated libusb. And just to eliminate any further question you may have on this, we will of course carry any commit applied to one library into the other, up to the 1.0.18 release, in about 2 weeks time, so that the actual releases too are virtually identical. o The old .org website is no longer used by the libusb project. The main website has now moved to: http://libusb.info What are the reasons for abandoning the old .org domain? It's controlled by someone who doesn't like libusbx and with whom we have been unable to reach any form of compromise for many years now (which is the reason there was a libusbx fork in the first place). Now that we have regained control of the SourceForge project, we consider that losing the old domain is an acceptable *temporary* drawback, if it eventually means that developers can access a living and breathing libusb back again. I think it should at least contain a forward/link to the new site since a huge amount of old libusb users who are not reading this list will direct their browsers directly to libusb.org and thereby never find out about the new releases. There's nothing we can do about the content of the old .org site. On the other hand, *you* and everybody here, can help make sure that people looking for libusb will find the libusb.info site faster, by helping publicizing that http://libusb.info is the new home of libusb, as well as ceasing to mention the URL for the old site altogether. It's unfortunate that we have to switch domains, but then again, an Open Source project needs not have a domain with a specific extension. As soon as a critical mass of people start referencing the home page that the project indicates, search engines will also reference it, and people will find that page first. Regards, /Pete -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] break from never ending loop. fix #76. (#167)
Thanks for the patch. We'll see what we can do to integrate it, but can you tell us a bit more about the circumstances where this behaviour occurs, and how easy or difficult it is to produce (i.e. do you see the infinite loop consistently happening in an app, or is it a bit more random)? /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/167#issuecomment-31981250-- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Fix example hotplug code in comment to make it compile and work
Unless we find something critical, I STRONGLY vote to delay it until after 1.0.18, even if it's doc. As Murphy's day (yesterday) taught me, if there's anything that can go wrong when duplicating work, it will go wrong. The github sudden breakage [1], which you are aware of, and which thankfully happened before we went live, was only the tip of the iceberg (for instance, the machine I used to upload the doc from has no working doxygen right now...). If something's gotta break, I'd rather have it break when there's only a single release being pushed out... ;) Of course, anything that looks critical is go (and right now I'm wondering if the infinite loop fix that was just submitted qualifies)... Regards, /Pete [1] https://status.github.com/messages -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: winusb backend device not successfully enumerated on USB 3.0 ports under Windows 7 (#67)
No input from OP (especially wrt the USBView test) = closing issue. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/67#issuecomment-31865706-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: winusb backend device not successfully enumerated on USB 3.0 ports under Windows 7 (#67)
Closed #67. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/67-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] Announcing libusbx-1.0.18-rc1
All, I am pleased to announce libusbx-1.0.18-rc1. The most important news with regards to this release is that v1.0.18 (currently planned in 2 weeks time) will be the very last release of libusbx, as we are finally merging back with libusb. As a result, we are issuing two parallel 1.0.18 releases: one for libusbx and one for libusb, with parallel RCs as well (there will be an announcement for libusb 1.0.18 RC1 shortly), and with the patches from one repo being carried over into the other, until release date. As far as the code is concerned, the current libusb repository and the current libusbx repository can be considered identical, and of course the libraries are fully interchangeable, up to the latest libusbx features and bug fixes. The only difference between the library stands in one commit, that updates most of the comments and documentation that was referencing libusbx, into referencing the updated libusb. As your schedule permits, we will encourage current libusbx users and followers to start switching to libusb, by using the following: o Main site: http://libusb.info o Git repository: https://github.com/libusb/libusb o SF repository: https://sourceforge.net/projects/libusb/ o Mailing list: libusb-de...@lists.sourceforge.net Of course, even after libusbx v1.0.18 is out, libusbx will not be retired right away: the existing site and repositories will continue to be operational, and we will continue to monitor this mailing list. For those interested the full ChangeLog for this release is below. As usual, you can find links to the libusbx RC, including the Windows RC binaries by using the Download menu from http://libusbx.org... or http://libusb.info, if you are ready to make the switch to libusb. Regards, /Pete 2014-01-08: v1.0.18-rc1 * Last release of libusbx, as the project is merging back again with libusb. As a result, continuation of the project will now occur from the following: o Main site: http://libusb.info o Git repository: https://github.com/libusb/libusb o SF repository: https://sourceforge.net/projects/libusb/ o Mailing list: libusb-de...@lists.sourceforge.net (registration req.) * Fix multiple memory leaks * Fix a crash when HID transfers return no data on Windows * Ensure all pending events are consumed * Improve Android and ucLinux support * Multiple Windows improvements (error logging, VS2013, VIA xHCI support) * Multiple OS X improvements (broken compilation, SIGFPE, 64bit support) -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] Announcing libusb-1.0.18-rc1
All, It is my great pleasure to announce libusb-1.0.18 RC1, which marks the long awaited merge-back of libusbx with libusb! With this release candidate (and upcoming release), we are finally consolidating the two projects back into one, as well as bringing the many bug fixes and new features of libusbx, into libusb, for the benefit of all users. With this update, we also had to make a few changes to some of the existing URLs, so if you are an existing user of libusb, or libusbx, please take note of the following: o The old .org website is no longer used by the libusb project. The main website has now moved to: http://libusb.info o The git repository has also been moved to github: https://github.com/libusb/libusb If you want to clone the latest version, you can use: git clone https://github.com/libusb/libusb.git o The github facilities are also now used for Wiki and issue tracker. o The libusb SourceForge project (where the source binary tarballs as well the API documentation are help) is unchanged o The libusb mailing list is also unchanged. To check the RC, you are invited to go http://libusb.info, and use the Download menu, which should give you access to both the libusb 1.0.18 RC1 source tarball, as well as the RC1 Windows binaries. Of course, if you find any issue with the RC, you are encouraged to report on this mailing list, or github. Finally, because as the changes would be too long to copy/paste here, as there hasn't been any official libusb release since v1.0.9, you can take a look at the complete libusb Changelog by visiting: http://log.libusb.info Regards, /Pete -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Darwin: submit_bulk_transfer crashes with EXC_ARITHMETIC (#136)
Closed #136 via 314f4ff998f6ba63607ce3be6cd7193a39cd1f78. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/136-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Darwin: When an unknown error fall back to error code (#117)
Closed #117 via b1bbea6f4f5cadc8ba2f48ae077f0c4ac339c3cc. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/117-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Darwin: Fix format of 64-bit sessionIDs in log messages (#153)
Closed #153 via 0500232303fe706dbe538290a49869f1dadf90af. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/153-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Fix error formatting for SetupAPI errors (#166)
Closed #166 via 8b46e1c088167eb86b1712765896e2f17d70d148. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/166-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Android: Enable building on all Android architectures, including MIPS (working around an MIPS NDK linker bug). (#134)
Closed #134 via 650e22508f6d595d73d565423cb06b14049bd3af. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/134-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Adding support for compiling at *-linux-android platform (#154)
Closed #154 via 7e3de5de095a493accc77081fb384be8e9144250. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/154-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Use WinUSB when available to avoid driver IOCTL bugs. (#137)
I still don't think this is a satisfactory proposition, and I don't believe we want something that removes functionality just to work around a bug that, by all means, should not be libusb's to fix. I am therefore going to close the request. If someone needs that kind of workaround, they can always apply the one proposed here to their own builds of libusb. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/137#issuecomment-31307167-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Fix error formatting for SetupAPI errors (#166)
On second thought, looking at the `HRESULT_FROM_SETUPAPI` macro, I think we can probably avoid creating a new function call, by simply applying `HRESULT_FROM_SETUPAPI` in `windows_error_str()` when it's not able to translate the message. Will try to work something out in that direction. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/166#issuecomment-31307314-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Fix error formatting for SetupAPI errors (#166)
Sounds good. I'll try to apply this patch for the next release. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/166#issuecomment-30901861-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Add isochronous support via libusbk backend (#164)
I'm not sure it's that easy, and I'll tell you why. That would explain why I've been having all the trouble in the world getting Windows 7 accept the Windows 8.1 WinUSB driver and DLL last time I tried it (can't remember the error I was getting, but Windows 7 sure didn't seem happy with it). Of course, one of the problems we have (AFAIK) is that Microsoft has not published a WinUSB CoInstaller for Windows 8.1. Or at least I wasn't able to locate one around the time Windows 8.1 was released. Then again, even if there's a minimum client restriction, is it still very easy to check for both the ProcAddress presence and the Windows version. In other words, even if it needs adjusting as we go along, I don't really see detecting ISOC support from WinUSB as that big of an issue. I have asked for clarification on this issue from the WDK team, but there is no response yet. Thanks for doing this. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/164#issuecomment-30454829-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Add isochronous support via libusbk backend (#164)
Those components have dependencies on other Win 8.1 components, so they cannot be copied to earlier systems. Which is fine and all, but still doesn't say much about whether a Windows 7 compatible version of the ISOC WinUSB driver could be sorted out, if Microsoft really wanted to... libusbK seems to be doing ISOC on Windows 7 without too much trouble, so it's hard to be convinced that the OS is the real limitation. So, why don't I like it? Primarily because this represents a change in philosophy. So long compatibility with previous platforms... Between this and the oh-so-suspicious absence of an SP2 for Windows 7 (which of course would be a great place to push dependencies for an updated WinUSB driver), it does look like Microsoft if trying hard to neglect Windows 7 users in a (desperate?) attempt to have them upgrade to 8.x... /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/164#issuecomment-30459345-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Add isochronous support via libusbk backend (#164)
What is the libusb/libusbx merge? Pulling changes from libusb into libusbx, or the other way, or both? It's merging libusbx and libusb back together into a single website, git repository and so on. This is something that we'd said we'd do more than 9 month ago, so now's probably a good time to try to keep our word... ;) Is there some dependency between hotplug support and isoc that I'm not aware of? Not really. The issue here is that there's currently only one official libusbx Windows maintainer (me), who started looking at the [Windows hotplug patch](https://github.com/libusbx/libusbx/issues/9) that was submitted quite a few months ago now, and then had little choice but to move to non-libusb things before I sould push things further for official integration. So the integration of this patch has been in limbo for about 2 months now, and I don't think it would be fair for the person who submitted it, and is still waiting on its integration, if a brand new major feature, such as libusbK isoc was integrated first. For what is worth, I do try to review/test submitted patches before integrating them, especially if they are major features, so it's not just a matter of pushing the Merge pull request button. However I will be the first to admit that this can create a major bottleneck, and actually wouldn't mind seeing someone taking over Windows maintenance altogether, if they have the time, to avoid this kind of damaging situation. Now, considering that we already had a milestone set for January for the libusb merge (which existed before you submitted your patch), and know that there are a bunch of our users waiting on this to happen that's what I'm planning to spend my time on next. Then, as it's probable that Manuel must be despairing to ever see his work integrated, Windows hotplug is what I'll turn to after that. Only once that's sorted out am I planning to take a closer look at your patch. Maybe it'll take 5 minutes to review and integrate (though I sure would like to take a quick look at WinUSB 8.1 ISOC while I do so), but processing stuff submitted to us more or less in a FIFO fashion does look like the fairer approach to me. d Are you suggesting WinUSB isoc support would be merged before Windows hotplug, libusb/libusbx merge? No. What I'm saying is (Not trying to play the busier-than-thou card here -- pretty sure you are probably as busy as I am, and would like see this thing gone ASAP, so that you can move on to some other things), since I'm also planning to have releases of other stuff (namely Rufus, libwdi Zadig) over the coming couple of months, with yet-to-be-coded features, and since libusb merge Windows hoptplug take precedence, I'm just trying to warn you that you're probably better off counting that not much happen with your patch for the next couple of months __if I'm the one tasked to integrate it__. And thus you might want to use that time to add a related feature, if you have the scope. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/164#issuecomment-30462654-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Add VS2013 solution and project files (#162)
Closed #162 via 805cc3ec40b5b6314e8cef8fb8cd9f8d4e95f293. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/162-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Add isochronous support via libusbk backend (#164)
Now that I think about it, and especially as I still have some hope that it might be possible to pick the Windows 8.1 WinUSB driver and install it on Windows 7 Windows 8.0 machines, the right way to find if WinUSB isoc is supported is to use `GetProcAddress()` on the WinUSB DLL, to see if it has a `WinUsb_ReadIsochPipe` entry. Besides, `GetProcAddress()` is already what we're using to get our WinUSB entrypoints in [winusbx_init](https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L2543), so it should be pretty straightforward to check if the address of the calls we need is NULL in the isoc libusb functions, and return not supported if that's the case. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/164#issuecomment-30356211-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Add VS2013 solution and project files (#162)
The main difference is which runtime each one targets, which is a simple change. Can't you just use a simple search/replace script to update the `PlatformToolset`? I __really__ would prefer avoid adding solution files that are not going to be used by any of our maintainers for the foreseeable future, as it's a recipe for sync issues. Your second proposal is pretty much the same as the first one, but in disguise (instead of having 2x the vcxproj files, with half of them going untested, we have vcxproj files that are twice as large, with half of their content going untested). On the other hand, I wouldn't have much of an objection adding a script in our project that replaces all our `PlatformToolsetv110/PlatformToolset` instances with `PlatformToolsetv120/PlatformToolset`, to turn the 2012 files into 2013 compatible ones. This might even be possible [in pure batch](http://www.dostips.com/DtCodeBatchFiles.php#Batch.FindAndReplace). I also have no objection pushing the .gitignore changes if you need them (though I'll probably wait until we have another commit to piggyback on that) NB: I tried removing `PlatformToolset` from our existing 2012 files, in the hope that VS would simply fill the missing part with the latest, but it complains on open. I also tried setting it to `v120`, in case Microsoft actually tried not to screw their VS users and planned ahead for a change, but while it opened just fine in 2012, it produced errors during compilation. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/162#issuecomment-30279160-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Add isochronous support via libusbk backend (#164)
Well, if I'm the one doing it, integration of libusbK isoc support is not going to happen before libusb and libusbx are merged back and Windows hotplug support is in. Considering that I had to leave Windows hotplug on standby for a few months now (I'll come back to it once the merge with libusb is done), I'm afraid you probably have quite some time before isochronous support is integrated. And that's the reason why I asked if you wanted to look into WinUSB in the meantime... /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/164#issuecomment-30280871-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Add isochronous support via libusbk backend (#164)
Further, since WinUSB isoc is only available on Windows 8.1, I'm not sure within the current libusbx framework how one would check the platform and notify the API user that WinUSB does or does not have isoc support on the current platform. Easy. We already have part of a Windows version detection call that is executed on `libusb_init()`. All `_submit_iso_transfer()` has to do then is check if the WinUSBX subapi is WinUSB and if the version set during init, to either process the call or return `LIBUSB_ERROR_NOT_SUPPORTED`. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/164#issuecomment-30281481-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Add VS2013 solution and project files (#162)
Hi Josh, Thanks for the files, but the current policy is that we only add solution and project files for the dev env that active libusbx maintainers are using, and right now, I'm not aware of any of us using VS2013 or planning to upgrade to 2013 anytime soon. This policy stems from libusb/libusbx previously including support for some visual studio platforms that weren't tested and were left broken for months before we got notified of it (as a matter of fact, I do believe that the MSVC6 support we have is currently broken -- we just never go a chance to remove it). Unless you volunteer to test VS2013 on regular basis (at least once a month) to confirm that it isn't broken, as well as perform the necessary maintenance (clone any changes that may be added to VS2012, such as new samples, options being changed, etc) and support (if anyone has any complaint about VS2013, I expect you to step up on either the libusb or libusbx mailing lists), I'm not sure I want to add VS2013, when the upgrade from VS2012 should do. Let us know, /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/162#issuecomment-30193894-- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: Add isochronous support via libusbk backend (#164)
Thanks, but is there any possibility you could see how this fits with the [WinUSB isochronous support that was added by Microsoft for the WinUSB driver of Windows 8.1](http://msdn.microsoft.com/en-us/library/windows/hardware/dn303354%28v=vs.85%29.aspx#usb_wdk)? Ideally, we want to avoid adding code that is specific to libusbK only to find out that we need to do something completely different for WinUSB? Is there any chance you could look into WinUSB as well? --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/164#issuecomment-30194086-- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] libusb_interrupt_transfer Segmentation fault. (#160)
Is libusbx still being maintained, or is all the energy focused on the great rejoining? Don't know about the others, but for the past few weeks my energy has been focused entirely on the [Rufus v1.4.0 release](http://rufus.akeo.ie) (which is now in beta at long last - pfew!). I also had to release a new [Zadig](http://zadig.akeo.ie) a couple days ago, since people were encountering an annoying issue. I'll be back to libusb/libusbx very soon, with this bug the very first thing I'm planning to address. In case you really want to know, you always can find out whether I'm working on libusb/libusbx or something else by having a look [here](https://github.com/pbatard/libwdi/wiki/Backlog) or [here](https://github.com/pbatard?tab=activity). --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/160#issuecomment-29015623-- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Windows 8 WCID WinUSB error -12
On 2013.09.30 08:26, Ramon Zambelli wrote: I modified my device as you specified on the wiki and it now works as expected. Thanks a lot!!! I'm very happy to hear that. Thanks for your patience while we looked into it. Regards, /Pete -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Windows 8 WCID WinUSB error -12
Hi, Sorry for the late reply. I finally managed to test and reproduce the issue, as well as figure out what you can do to avoid it (and no, using Zadig is not an acceptable workaround - it completely defeats the purpose of using WCID in the first place). What you really want to do to keep using WCID and avoid the problem is set DeviceInterfaceGUIDs (with an 's') as a REG_MULTI_SZ in the Microsoft Extended Properties Feature Descriptor (the one with wIndex 5), in your WCID descritptors. If you do that, libusbx should be able to work with the WCID WinUSB driver installed by Windows for the second interface. Also, don't forget that, since you use a REG_MULTI_SZ, you'll need a double NUL to terminate the GUID string. Basically, you want your device to return something that looks like the attached output, as produced by xusb. NB1: this specific device already has an MTP record for interface 0, which is why you get an extra MTP record besides the WinUSB one for the Microsoft Compatible ID Feature Descriptor at wIndex 4. NB2: I'm using a modified version of xusb to get the descriptor at wIndex 5 since WinUSB has a restriction that forces the wIndex to the interface number when issuing an interface request. I also set the device firmware is also set to return the wIndex 5 descriptor when issuing a Device request. It's a long, pure Microsoft annoyance story... NB3: Yup, I am adding WCID support to Android, since it's using WinUSB for debug. I'm hoping to push a patch upstream at some stage... NB4: I also tested that should also be able to get away with using a REG_SZ as long as you use DeviceInterfaceGUIDs with a s, but I guess if you're using plural, it should technically be a MULTI_SZ. As to where the issue stems from, it seems that, while Windows has logic that will list DeviceInterfaceGUID (without 's') registry entries when requesting the DeviceInterfaceGUIDs (which is what we do at [1]), that logic seems to break down if the interfaces are not handled by the same driver. In other words, during the enumeration where we ask Windows for all the GUIDs we should parse using SetupDi, identify devices using WinUSB that we should support, we fail to get the GUID if the device is composite an has only a DeviceInterfaceGUID property on an interface other than the first. Now, if the GUID for that interface is provided under DeviceInterfaceGUIDs with an 's', it is properly returned when we query it. In light of this, I guess we should probably update our enum code to query both the DeviceInterfaceGUID and DeviceInterfaceGUIDs, but of course that will mean adding logic to remove duplicate GUIDs. And while we're at it, we probably want to treat what we get from the DeviceInterfaceGUID query as a REG_MULTI_SZ, and consider that we may get more than one GUID there, which we don't do right now. If someone wants to take a stab at the windows_usb.c update, please go for it, as I'm going to continue to treat this as lower priority (due to time constraints). For now, I'm just going to modify the WCID wiki to advise the use of DeviceInterfaceGUIDs instead of DeviceInterfaceGUID. But I must say that allowing both DeviceInterfaceGUID and DeviceInterfaceGUIDs to define essentially the same property was a sure way to create problems such as this one appear. Had Microsoft stuck with using a single property name for the list of GUIDs, we would definitely have avoided all this mess (and for the record, we followed official MS documentation for using either one of those in WCID and the infs generated by Zadig)... Regards, /Pete [1] https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L1484 D:\libusbx\Win32\Debug\examplesxusb 18d1:4ee2 Using libusbx v1.0.17.10842 Opening device 18D1:4EE2... Reading device descriptor: length: 18 device class: 0 S/N: 3 VID:PID: 18D1:4EE2 bcdDevice: 0228 iMan:iProd:iSer: 1:2:3 nb confs: 1 Reading BOS descriptor: no descriptor Reading first configuration descriptor: nb interfaces: 2 interface[0]: id = 0 interface[0].altsetting[0]: num endpoints = 3 Class.SubClass.Protocol: FF.FF.00 endpoint[0].address: 81 max packet size: 0200 polling interval: 00 endpoint[1].address: 01 max packet size: 0200 polling interval: 00 endpoint[2].address: 82 max packet size: 001C polling interval: 06 interface[1]: id = 1 interface[1].altsetting[0]: num endpoints = 2 Class.SubClass.Protocol: FF.42.01 endpoint[0].address: 83 max packet size: 0200 polling interval: 00 endpoint[1].address: 02 max packet size: 0200 polling interval: 00 Claiming interface 0... Failed. Claiming interface 1... Reading string descriptors: String (0x01): asus String (0x02): Nexus 7 String (0x03):
Re: [Libusbx-devel] [libusbx] Windows: libusbx fails to access WCID interface of a USB composite device (#140)
The proper workaround/fix is to define `DeviceInterfaceGUIDs` (with an s) as a `REG_MULTI_SZ` in the WCID descriptor. If you do that, then the GUID of your WCID interface will be picked up by libusbx, whereas if using `DeviceInterfaceGUID` (without the s) it won't. We also should try to update the Windows enumeration as per (this e-mail)[http://libusbx.1081486.n5.nabble.com/Libusbx-devel-RFC-0-2-Add-support-for-USB-3-bulk-streams-tp1911p2029.html] /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/140#issuecomment-25328155-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: ASMedia XHCI enumeration issues. (#147)
Thanks. I don't mind the idea of not using APIs that seem to be flaky (or rather, that hardware manufacturers appear to have overlooked) to figure out the port number, but on the other hand, this adds a lot of code for something that we used to get with a single API call, and for something as elementary as getting the OS tell us which port a device is connected to. If we find that `SPDRP_LOCATION_INFORMATION` works all the time, it would drastically simplify the change we need to make to get a port number. Also, we need to be careful about issuing IOCTLs to hubs. Some of these __may__ generate bus traffic, and we have a bunch of people who get very annoyed about traffic being issued to the bus during enum, as it may disrupt ongoing time-critical transfers. I'll try to take a closer look at your proposal when I get a chance. Thanks again for taking the time to investigate and submit it. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/147#issuecomment-25328384-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: ASMedia XHCI enumeration issues. (#147)
Got a response from ASMedia, which used a lot of polite words to tell me 'We don't talk to end users, go away' Glad we could __publicly__ establish that ASMedia doesn't seem to care about their actual customers. Hopefully this will help potential buyers of ASMedia-based hardware decide whether they want to use products from a company which, if your report is correct, appears to have little interest in receiving feedback from end users, in order to improve their products. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/147#issuecomment-25196590-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: ASMedia XHCI enumeration issues. (#147)
Just want to copy the comments on top of enum.c here. Yeah, I can read code and comments too, __when I have the time__. I was simply hoping that you could speed up things by doing the analysis and tell us exactly what process is used by usbview to compute the port number (NB: the rest of the process is fairly close to what we do for our enum, if you look at what each pass accomplishes. As a matter of fact, usbview was used as a reference when crafting our enumeration) As long as it requires 2 different API calls, that each essentially return the same element we are interested in, albeit in a slightly different form, I don't see how we can integrate this patch. Now, you're of course free to decide whether you want to help us and ASMedia users further, by doing the analysis work above, or just leave that to whichever libusb developer will get a chance to do it, when/if they get a chance to do it. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/147#issuecomment-25197612-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: ASMedia XHCI enumeration issues. (#147)
but going down the path of 'i hope people see this and don't buy products' seems a little... harsh? How about Renesas then? Pretty much the same business model, except, and I speak from experience here, users can actually reach out to their developers when they encounter an issue. I was able to have a technical discussion, with their developers, fairly easily, with regards to an issue we had with regards to root hubs not being listed through Renesas hardware. Some companies __get__ customer care. Other don't. It's just not a buzz word to throw around. Final users are your customers, always. If you do everything in your power so that your developers never hear from them, then __I__ will be reluctant to use your hardware or software, and, what's more, I will not shy away from encouraging others not to do either, because endorsing the practice of ignoring end users or having them jump through hoops in order to speak to a physical person with the capability to help is not doing anybody any favour, including the company itself. In the age of the Internet, and as consumers and users, we have the power to render that one sided practice obsolete. Let's. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/147#issuecomment-25213966-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] How to access multiple interfaces on windows is different to linux?
On 2013.09.25 16:36, Kano wrote:
My question then I guess is: how do you do bulk transfers (read and write)
to all 4 interfaces? The method I use on Linux, fails on windows.
A control transfer is no problem since you effectively specify the
interface, but how do you do a bulk transfer?
Well, libusb_bulk_transfer takes an endpoint as parameter, and as
Endpoints can't be shared between two interfaces within a
configuration [1], specifying an endpoint effectively specifies the
interface you want to use as well.
In my linux code (which does work - it's been running for many days doing
I/Os non stop - at least 10 per second each, randomly, to all 4 interfaces)
To setup:
I open a handle then claim the interface 0 (as stated before)
Then I open a second handle and claim interface 1 on the 2nd handle
('claim' requires a handle)
Which doesn't have to be freshly baked. A libusb device handle
shouldn't become invalid as soon as you use it to claim an interface.
Have you simply tried reusing that one handle you got from your first
libusb_open() in every subsequent call that requires a handle?
We've been pretty much been advising you to avoid issuing multiple calls
to libusb_open(). Have you tried doing that?
I have 4 threads - each has it's own handle to talk to the interface it
is given.
Try a single thread (talking to as many interfaces as you like) using a
single handle. See if that works.
Then try to share that handle between your 4 threads.
I think that, by issuing multiple open from within multiple threads, you
may be hitting the WinUSB does not support multiple concurrent
applications limitation [2] (as I doubt MS will make much distinction
between a open from a thread and open from a process).
On that note, you may be interested to know that the first libusb_open()
call you issue for a libusb device on Windows will try to get an WinUSB
handle (which is internal and different from the public libusb handle)
for ALL of the interfaces it can access. So really, you shouldn't have
to issue open() over and over again.
Regards,
/Pete
[1]
http://msdn.microsoft.com/en-us/library/windows/hardware/hh920375%28v=vs.85%29.aspx
[2]
https://github.com/libusbx/libusbx/wiki/Windows-Backend#wiki-Known_Restrictions
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] [Windows] ASMedia XHCI enumeration issues. (#147)
And what happens if it's not in the `Port_#_Hub_#` format? Do we set all the ports from that hub as port 0? Also, what exactly does the ASMedia driver return as a string for this query? From what I'm seeing, your intent is to set the port number to zero, which is invalid, in the case of poking anything on an ASMedia connected hub, and pretend that everything's copacetic. Well, with the code less than 5 lines above pretty much saying if we can't retrieve valid port data, then we eliminate the device, it kind of looks like you are trying to hide your ASMedia annoyance (most likely a driver bug that ASMedia should be the ones to fix) under the rug. As such, I don't think this is something we can really go with: displacing the problem, rather than solving it, will only end up impacting other users. This may sound like an acceptable solution to you, but for everyone who expects consistency with how we assign port numbers, and/or uniquely identify a device, not so much... My other questions to you then are: - Have you contacted ASMedia support and asked them if they are aware that their driver is not compliant with Microsoft's API and breaks USB applications? What did they say? - Have you tried upgrading your ASMedia drivers to the latest version? /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/147#issuecomment-25055126-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)
OK, a few preliminary remarks: 1. TCHAR: No. Just no. Please get rid of this atrocity. Either you use an UTF-8 char* string (or you use a wchar_t if you must need UTF-16). Your use of TCHAR completely breaks VS2012 compilation right now and despite what Microsoft wants to make everybody believe, there is no justification for using TCHAR ever (except for letting Redmond get away with not doing [what they should have done about 15 years ago](http://www.utf8everywhere.org/)) 2. Be mindful that ``` int a; a = 1; int b; b = a+1; ``` Will not work on MS compilers. All the variable declarations must be at the top. Thus windows_usb.c lines 584 2366 also break MSVC compilation. 3. b9eae35836855367a0e779c349ae333db8564a3b = nope, not gonna work. MSVC doesn't have named initializers (and that's not limited to MSVC6). You need to revert this whole patch. 4. When the __existing__ code uses something like ``` int func(int a, int b, int c); ``` It's very bad manner to disregard the previous styling convention and introduce your new code with ``` int newfunc(int d, int e, int f) ``` Whoever was first to create a source gets to decide the styling convention, and everyone who comes after follows. Now, if you create a new sourcefile, you get to pick whatever you like (as long as it's not too wild), but if you add to an existing one, you just spend some time looking around at the existing style, and follow it. Same goes for using spaces in code addons where spaces are used. I see quite a few of these. Please use an editor that displays whitespace symbols and address your spaces vs tabs issues. Also, a proper git UI (such as TortoiseGit on Windows) is very efficient at letting you know when you're introducing whitespace issues and it's as annoying for a maintainer as it is for a submitter to see one's patch shot down simply because they didn't bother paying attention to whitespace issues. 5. f3dd52c02212c62e154972093d832f1b83f794f1 - I'm not sure how I feel about having emacs defs introduced to Windows specific files that __most__ people are going to edit on Windows, with editors that aren't emacs and that have their styling sensibly set __globally__ without a requirement to have it def'd within the file itself (ugh! Besides vi emacs anyway ;)). Can you imagine if every editor out there insisted on doing the same? We'd end up with a whole set of /* Joe's editor */ /* Bob's editor */ ... /* Bill's editor */ sections that'd end up taking more space than the actual payload of the file. Now, if you __must__ have it, and since OS X has already started doing some of that, I'll let it slide, but really, who in their right mind can justify that merging and multiplying editor specific presentation config data in each source of a project is a good idea. 6. If you don't have a Windows machine at hand, __strongly__ suggest that you install Wine and the latest __standalone__ WDK (I think [this](http://www.microsoft.com/en-us/download/details.aspx?id=11800) link should do), so that you can pick up on all the annoyances that the MS compiler is going to throw at you. If you have a Windows test machine (which I guess you probably do, since I don't see why you'd want to spend time on a Windows hp implementation in the first place), then it's even easier - just install the WDK, and run ddk_build.cmd in the msvc directory. By the way the WDK is free and is as close as you can get to MSVC if you can't afford the hefty Visual Studio license. It's also a good idea to test both cygwin MinGW compilation if you can. Basically, the first thing I'm going to do is check whatever errors and warnings come out out of MSVC (either WDK or VS2012), MinGW (one of 32 or 64 depending on how the stars are aligned) and cygwin. If either one of those doesn't compile cleanly, I'll ask you to make it so (and yeah, this kind of multiplies your amount of testing by 3 - welcome to not time consuming at all libusb Windows backend development!). If you try to address the above, I'll try to get a more serious look at your actual implementation (though it may be a couple more weeks before I actually do so). /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/9#issuecomment-24785359-- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] 2 patches to fix memory leaks in examples/ezusb.c
On 2013.09.19 23:06, Ludovic Rousseau wrote: The Coverity tool reported many memory leaks in examples/ezusb.c I fixed them in the attached patches (also available as https://github.com/libusbx/libusbx/pull/141) If no objections I will push them this nexy week-end. Haven't tested, but looks good. No objection for a push. Thanks for fixing this. Regards, /Pete -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)
Sounds good. As far as I'm concerned, it'll probably be another week or two before I am in a position to properly review your changes so I hope you're not in too much of a hurry. Also, we may apply [this](http://libusbx.1081486.n5.nabble.com/Libusbx-devel-RFC-0-3-Make-usbi-get-device-by-session-id-return-a-ref-to-the-found-device-td1898.html#a1896) as well as [this set](http://libusbx.1081486.n5.nabble.com/Libusbx-devel-RFC-Remove-fake-fds-from-Windows-backends-td1432.html) before we apply any of your changes, which may conflict with part of your proposal. As a result, we might ask you to rebase your branch after we've applied those, if that's OK. At any rate, thanks for working on a hotplug proposal that we should be in a position to integrate. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/9#issuecomment-24178549-- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Releasing 1.0.17 *final* coming Thursday ?
On 2013.09.03 08:42, Hans de Goede wrote: I plan to release 1.0.17 *final* coming Thursday. Sounds good to me. I'll see if I can run some tests with the RC on Windows today or tomorrow. At any rate, if you don't hear anything from me, consider that everything's green. I'll also try to push some Windows binaries on release day. In other news, I have just released Zadig v2.0.1.161 (the generic USB driver installer for Windows), so that it includes the libusbK v3.0.6.0 release driver. The other new feature with this release is that Zadig is now provided as an LZMA compressed executable (thanks to a recent UPX update) rather than a .7z that users need to uncompress themselves. Hopefully, this will make the installation of a libusb/libusb[x|win32|K] compatible driver even easier. And since I'm getting more and more dissatisfied with SourceForge's direction, the downloads for Zadig are now located at: http://zadig.akeo.ie Regards, /Pete -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Announcing libusbx-1.0.17-rc1
On 2013.09.02 05:52, Xiaofan Chen wrote: On Sat, Aug 31, 2013 at 12:21 AM, Gisle Vanem gisle.va...@gmail.com wrote: when I'm using '-Wp64' in my CFLAGS. This flag does not exist in VS2012. enable 64 bit porting warnings. I'm on a 32-bit WIndows: libusb/core.c(692) : warning C4267: '=' : conversion from 'size_t' to 'ssize_t', possible loss of data libusb/os/windows_usb.c(173) : warning C4267: '=' : conversion from 'size_t' to 'ssize_t', possible loss of data I'm not sure these matters. Did you see this with the default Visual C++2010 solution file settings for the 64bit build? I remember Pete's stand is to fix the warnings for the default settings but selective in fixing the warnings for non-default settings. Unless you go pedantic, I wouldn't want compilers to warn on size_t to ssize_t conversions, because that's something people are going to do all the time, and the expectation is that developers doing such conversion are fully aware that they're going to lose a bit for the sign when using super large values. As such, I'm not planning to take any action to silence these in the code, especially as we're talking about the number of discovered devices for the core.c one (= someone would need more than 2 billion of those connected on one machine for this to become an actual issue) and likewise, you'll need the OS to supply us with a 2 GB device string for the windows_usb.c one. Not gonna happen. Also, as Xiaofan highlighted, and since we don't really have the scope to to fix warnings for every compiler, below is the list of those I would consider canon, or officially supported, for libusb(x)/Windows: - Visual Studio 2012 - WDK 7600 - relatively recent version of MinGW32 - relatively recent version of MinGW-w64 - relatively recent on cygwin If you get a warning that isn't for a real issue and that isn't going to appear in any of the compilers above, I will expect you to fix it in your solution files. Now, of course, you will notice that we have VS2010 and VS2005 and even MSVC6 solution files, but we make no promise that these are up to date or even in working state. Of course, if you want to send a patch that we can apply to these solution files, we'll have no problem applying them. - priv-depth = parent_priv-depth + 1; + priv-depth = 0xff (parent_priv-depth + 1); Hmm, I think this is not needed since depth can not be more than 8 as per USB standard. Yeah. I distinctively remember looking for the maximum numbers of hubs that an USB device could go through, with regards to this line of code, and concluding that we could safely ignore the overflow. If we are going to change that line, it'd be to add a message that says Congratulations, you ignored the USB specs and must have horrendous latency. Thus, unless we get that warning in one of the canon compilers, I'm not planning to do anything here. I other news, I have now pushed a fix for the VS2012/x64 conversion warning. Regards, /Pete -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Reading device descriptor and config descriptor from WinUsb
On 2013.08.22 19:29, Juan Lang wrote: Renesas uPD720201/uPD720202 (dev 0194), driver version 2.0.32.0. (I'm not certain which chip, I haven't looked at the board to identify.) If you're using driver version 2.0.32.0 then your chip is a uPD720200/uPD720200A. uPD720201/uPD720202 would use driver version 3.x (on my system it's 3.0.23.0) Also, 2.0.32.0 is an old and buggy driver, which should NOT be used by anyone. Renesas released 2.1.16.0 years ago now, so if you see an apparent problem with the driver, at the very least, you should first try to look for an upgrade. The latest driver should be 2.1.39.0. This is actually indicated very prominently at the top of the Windows page for libusbx (http://windows.libusbx.org) and what's more the error you got is the exact error that we reference in the thread linked there. And yeah, right now the link to download the updated drivers doesn't work, but that's because the guys who used to host the driver files are in the process of redesigning their sites (and for some unfathomable reason, Renesas chose not to provide their own drivers on their site), so you'll have to google around to find a copy. For what is worth, I have re-tested both uPD720200/uPD720200A uPD720201/uPD720202 with the latest drivers, and found no issue (but you want to make sure that you unplug and replug the device before running your test, in case you switch drivers). Now, considering that it's very likely that once you upgrade your Renesas drivers, as you should have done long ago, you will also confirm that your issue disappears, and that I can't help but have some doubts about the freshness of your TI and Intel drivers, I don't think I'm going to want to touch any proposal that aims at working around broken drivers, even more so if you aren't going to contact the manufacturers in the fist place. This is because: 1. Unless you can prove otherwise, it'll really be Intel or TI's job to fix their own bugs (as Renesas did), especially as, unlike us, they do have paid developers whose job it is to do just that. 2. You shouldn't equate the fact that we are easier to reach as an indication that we are going to be more willing to spend time to address a problem you encounter, and that seems to have very little to do with our software. 3. Both the IOCTLs are used by Microsoft's UsbView sample, which is as close to an official test application to validate an USB driver as you're gonna get from MS (and what's more, is an app that comes with the driver development kit). If TI and Intel failed to properly support these IOCTLs, something tells me that they haven't tried very hard when it comes to designing their drivers... I have a hack that works for me by falling back to WinUsb when these ioctls fail, but it's pretty hacky since I don't actually know (in GEN_PASS) whether the device is a WinUsb device or not. I'll work on postponing the ioctls until DEV_PASS to have something a little more concrete (and less ugly) to propose. Unless somebody else has any inclination to review and test a workaround, that's likely to break other stuff, since you mentioned that you'd have to remove stuff that you don't really understand the use of, you're going to waste your time. A much more productive use of your time is to first make sure you use the latest drivers always, and, in case you find they are still broken, ask the manufacturer if they are aware of the issue, and what they plan to do about it. Depending on the outcome of the above, I'll be more than happy to update the Windows page and tell our users what hardware or software they should steer away from, as we did with Renesas. Regards, /Pete -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Accessing composite devices using interface association
On 2013.08.16 04:27, Xiaofan Chen wrote: And hopefully now Pete or others can come out a proper fix with all the information. I have way too much lined up, so I have to drop stuff that I know I'll never get a chance to look at. Devising a fix with regards to IADs is one of those. If someone proposes a patch, I *may* try to look at it, but that'll be about it. Regards, /Pete -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: libusb_dll_2010.vcxproj link errors (#129)
Closed #129 via 368d613a17a3d768a7f434b886a8299f13711f8d. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/129 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx Windows warnings
On 2013.08.13 00:19, Xiaofan Chen wrote: The x86 build will not have the warning, the x64 version will have the warning. Aha. Now that makes sense, and I got the warning too. Fixed and pushed. Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Accessing composite devices using interface association
Hi Jan, On 2013.08.13 16:15, Jan Becvar wrote: Forgot to add that my idea/hope was that libusbx, when setting backend of a composite interface, could check if this is not by chance first interface of an IAD-collection and if so, assign the same backend to the other interfaces of the collection as well. But I don't know in the moment, if such approach wouldn't interfere with the general design of libusbx or with one of the libusbx-supported drivers. It's more a case of this is a problem that very few people are expected to encounter without being able to use either the workaround of replacing the composite parent driver or have their app figure out which interfaces are accessible from libusb and which aren't, so we're not going to invest much resources into solving it (too few developers, too little time). If it's of interest to you, eventually, we are planning to provide an interface that will allow Windows users to gain access to Windows specific data, such as the name of the driver being used to access a device/interface and/or whether it is libusb compatible. The idea then would be that you would use that information in your app to decide which interfaces are accessible. Unless we get many requests to add logic to allow additional interface access based on the driver, we'll leave libusb users add that logic in their application instead. As you will understand, adding complexity in the library for uncommon situations that can be handled at the app level is something we'd prefer to avoid. The reason is it introduces points of failure that then need to be tested forever and, unlike other software, automating the testing of a library that relies on the presence of external hardware devices isn't a problem that has a quick and easy solution. Microsoft decided to present devices with multiple interfaces as independent devices on Windows by default, so if your application targets Windows, you're probably better off trying to work within this restriction instead. There's only so much that libusb will try to abstract when the OS isn't exactly cooperative. Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Accessing composite devices using interface association
On 2013.08.14 00:21, Xiaofan Chen wrote: The 2nd option is not possible without changes in libusbx. Right now it is not possible to access the other interfaces other than the first interface in an interface collection of a USB IAD device as of now, even though the supported driver (eg: WinUSB) is used to associate with the interface collection. I'm also worried about this part from [1]: Client drivers cannot access IAD descriptors directly. So it is an issue with libusbx for interface collection inside USB IAD device. Now that I realized that it is not possible to sort out the issue in libwdi/Zadig, then the only fix possible is to change libsubx to parse the IAD descriptors (interface collections). Which may or may not be possible, still as per [1]: Host software cannot retrieve IADs directly with a GetDescriptor request. As far as WinUSB is concerned, I think the best we can get is WinUsb_GetAssociatedInterface(), but that what we're already trying to use. We may be able to fare better with libusb0/libusbK, since the doc seems to say that client drivers can query the composite parent, but now we need to modify external drivers, and we still can't solve anything when WinUSB is in use. BTW, libusbx Windows also does not support Multiple HID top level collections (only the first top level collection will be used). The situation is a bit similar here. Yeah, but I don't think Jan can use HID, and you can't really force install the HID driver anyway. I also think this the HID situation is a limitation from the OS too (i.e. nothing we can do about it). On 2013.08.13 20:48, Jan Becvar wrote: The Windows specific info's would be surely useful for various purposes, is that already somewhere on the roadmap? I don't think it is. That's partly because I personally have no idea in which milestone we should add this (don't want to give users false hope about getting it in version x.y.z) and also because that's not a feature I'm likely to forget about. However I'm not sure if I get right your notes about checking which interfaces are accessible. Am I right that such info could be mainly used to fail gracefully, because it will not help me get the other interfaces of the association group accessible through libusbx if the driver is attached to MI_00 rather than to the composite parent? I'm considering this from the perspective of: If you don't want to replace the composite parent, you shouldn't be trying to consider these interfaces as part of the same device, but as multiple independent devices, and write your app from that perspective. In other words, you should try to forget about IADs for the time being as Windows is not well suited to handle IAD in a generic fashion. If you were hoping to get anything related to this implemented quickly, you're only going to be disappointed. On that topic, I'm gonna be away for a few days starting now, so please don't expect anything from me for a while. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff540054%28v=vs.85%29.aspx -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Make libusbx accept an optional policy structure that specifies how logging and/or memory allocation work. (#128)
This is a bit too much to digest, as far as I'm concerned. Unless you can submit your changes as patches that apply cleanly on top of the latest libusbx, it's unlikely that we are going to spend a lot of time looking at them. There's just too much work involved in doing that and our resources are limited. Can you please try to break down what you need in a series of isolated patches that could be applied on top of the current master? You also may get more feedback on these patches if you subscribe to the [mailing list](https://lists.sourceforge.net/lists/listinfo/libusbx-devel) and submit them there. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/128#issuecomment-22523613 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx Windows warnings
On 2013.08.12 14:15, Xiaofan Chen wrote: Just tried VS2012 under Windows 8 and there is a warning for latest git tree. It is probably better to fix this as well for 1.0.17 release. ..\libusb\os\windows_usb.c(1768): warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss of data I can fix that, but I don't get it in Windows 7, and I don't really understand how the compiler would be influenced purely by the version of Windows it is running on. Do you get the same warning on Windows 7? Or is there anything you set in your VS2012 installation on Windows 8, such as enabling extra warnings. I'd rather figure out why your Windows 8 installation produces more warnings than my Windows 7 one, than have to fix a warning I never get every other week... Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: libusb_dll_2010.vcxproj link errors (#129)
I'll just point out that I don't believe anybody is testing the project with VS2010 any longer. As far as I'm concerned, I'm using VS2012 exclusively for Visual Studio, and I have no plans to test earlier versions of Visual Studio, so most of these projects update come from copy/paste and manual editing of the files. I will continue to rely on people using these versions to send patches in case anything gets broken. /Pete --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/129#issuecomment-22525207 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Windows: libusb_dll_2010.vcxproj link errors (#129)
Closed #129 via d28ab4bf13eb101f35d3543a3b2c2ca51a98e19d. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/129 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Android build files and improved logging patches, (was Improved log in non-console applications and Android)
The Android patches have now been merged into 2 individual commits and pushed. I tested compilation with the NDK (on cygwin) and everything looked OK. Here's what I changed: - Edited the README to advise using a global $NDK variable, since this is what google seem to advise too. - Use libusb rather than LibUsb as the log write facility. - Fixed a non Android related issue we had where LIBUSB_LOG_LEVEL_NONE would not silence messages. Once again, thanks for these patches. Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Android build files and improved logging patches, (was Improved log in non-console applications and Android)
On 2013.08.09 11:51, Toby Gray wrote: I'll try to look at the Android patches tomorrow, Well, it'll most likely be tomorrow's tomorrow now... unless someone is in a better position to test them, coz I sure don't have any such capability atm. Were you planning on just testing they build or running on a device? I like testing runtimes, or at the very least compiling them - it avoids bad surprises. But seeing that I have neither an Android device, nor an Android toolchain installed, I thought I'd ask around to see if any of the other maintainers were interested... ;) If you are planning on testing on a device then you'll need to have root access to it I don't think I'd purchase an Android device unless I am certain to gain root access to it... Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Android build files and improved logging patches, (was Improved log in non-console applications and Android)
On 2013.08.08 18:35, Toby Gray wrote: I've attached a rebase of patches 1 to 4 onto the master branch of libusbx. Thanks. Much appreciated. I have now merged 12 and pushed it. Besides merging, the changes I added are: - Use the W facility for both CE and regular Windows. The thing is, if you're using anything above win2k, W is what Windows uses internally anyway, so it's not gonna hurt us any - Use CP_ACP rather than CP_UTF8, first because anything that's not Unicode MUST DIE, and second because me way one day want to send Unicode data using our existing facilities (regardless of whether DebugView is Unicode compliant or not). - Add a warning for builds that enabled --enable-system-log but don't have an OS logging facility. From what I gather, #warning is used by all the compilers we support, except MSVC, which means we should be fine. And yeah, I know we're duplicating the fputs() line, which we could probably factorize, but it's behind exclusive #ifdefs, so this kind of optimization won't matter one bit. - Added a UNUSED() guard for level, since I was picking a warning in VS2012 because of it. - Harmonized the way we reported defaults in configure.ac, since it was all over the place, and the standard that autotools seem to use is [default=yes/no]. Looks more streamlined that way. Normally, I'd wait 24 hours for review for something like this, but since we're gearing up towards RC, and I wouldn't mind finding out early if we broke any system, I just pushed it. Of course, I ran tests with the usual suspects (VS, WDK, cygwin, Linux) and everything looked fine. Oh, and this new logging is very very cool, especially with the syslog facility added. Pretty sure some of our Linux users will be very glad to have this new capability. I'll try to look at the Android patches tomorrow, unless someone is in a better position to test them, coz I sure don't have any such capability atm. Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.08 21:42, Alan Stern wrote: I expect that, before you decided to add a quirk to the kernel, you must first have tried to get the manufacturer to fix compliance, by asking the user to contact them, and must have found that this effort went nowhere. This has happened. Not for every quirk, though. Besides, even if the manufacturer does fix the defect, that won't make any difference to all the devices that have already been shipped. Only for devices that have a non reflashable ROM, which is always a bad idea and a sure way for a manufacturer to indicate that they don't mind shortchanging their consumers. On the other hand, if you have anything reprogrammable on your device, and since the device will be plugged into a capable host always (with the USB specs also being quite accommodating for this kind of operation), providing a fix for devices that have already shipped shouldn't be that much of an issue. I know of a few USB flash drive manufacturers for instance providing low level utilities for their devices, some of them containing both the binary images of the controller's EEPROM, and a host utility (Windows only, as you may guess) to reflash them. Is that a fair assessment? Indeed. There's so much material in the mailing lists that it isn't easy to filter out any particular class of comments, but there are plenty of examples where people have complained about manufacturers' disregard for the specs. OK, I'm not going to doubt you there. I'm just wondering how strongly worded these comments might be, and how long it may take for them to have any kind of effect, if any. There is even a place in the USB mass-storage driver where, in despair of getting some vendors ever to fix their firmware, I added a blanket quirk for _all_ devices with those vendor IDs. (The vendors in question were Nokia, Nikon, Pentax, and Motorola, and the bug was that the devices would return the total number of data blocks they contained when asked for the highest available block number -- an off-by-one error.) I guess naming and shaming can work too, if the audience is large enough. Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH 1/1] Windows: fd_to_winfd() shouldn't treat fd 0 as invalid
This patch, and the two subsequent ones, have now been pushed. Thanks for identifying and fixing those. Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH v2 2/2] Windows: Make ENABLE_DEBUG_LOGGING enable logging output to the debugger.
On 2013.07.23 11:33, Toby Gray wrote: Do you have plans to look into adding a new config option for sending the debug output to the debugger, or do you want me to look into it? Yes I have. It was one of those bits of work that when I started looking at it I discovered several other things which were wrong. I send a series of patches, including the new config option, syslog support and Android support in the mail titled Improved log in non-console applications and Android on 9th July. Mailing list archive link: https://sourceforge.net/mailarchive/forum.php?thread_name=51DC431A.1050900%40realvnc.comforum_name=libusbx-devel I'll see if I can take a closer look at these tomorrow, for inclusion in the upcoming release. the event handling change is a big thing which might not make it in for a few release (if at all). Yeah. I think the additional tests should be fine (the more tests, the better!), and hopefully a no brainer to push, but since the common event handling is something we've been dragging for some time, it will require some scrutiny. Would it be possible to get the following three small fixes into master before the next release? Done. Regards, /Pete -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.06 14:57, Alan Stern wrote: I agree, it does need to change. This means putting more pressure on manufacturers, not on the users. And how else are you going to put pressure on manufacturers? If Linus and other kernel developers haven't been able to get nVidia to play fair, I'm curious about what other options you think are available. In my view, what Linus did, which is some form of public shaming through less than kind words being uttered in a public forum (that he may or may not have had an idea might end up getting a wider audience), is not that dissimilar to trying to rally a larger number of users to one's cause, one way or the other. Outside of being able to lure manufacturers to the immediate possibility of increased profits, putting pressure on them tends to boil down to 2 close factors: getting product consumers actively involved and voicing a common message (that if followed through, would result in loss of profit), or leading manufacturers to think that consumers are about to get actively involved and ask for the same thing. As such, the pressure you can apply is proportional to the number of users you can rally and their level of involvement. Holding users' devices hostage is not the way to do this Leaving hyperboles aside, I find that leaving users in ignorance, which seems to be what you advocate here (unless you make sure that each user of the quirky device is alerted to the behaviour and gets a chance to decide whether they want to contact the manufacturer about it), is much worse. And it's also kind of dismissive of the idea that users can actually understand that it _is_ the role of the manufacturer to fix issues, such as producing a device that isn't compliant with the specs. Sure, your local mechanic can fix that Ford Pinto's gas tank, so that you may avoid burning in a fire in case of a minor collision. But, as a car owner, you should understand that this individual action will accomplish nothing for all the _other_ Ford Pinto owners (or for future owners of a Ford car following the same design). Worse, it may very well send the very opposite message of what you really want which is a car where the gas tank does follow existing safety rules, and leave manufacturers with the idea that using a less than safe design for placing a gas tanks, or other critical components, is fair game, as long as only a small percentage of car owners have a chance to be affected... So I'm not gonna have that much of a problem saying Sure, I *could* fix your car. But since it doesn't follow basic safety rules, it's a potential deathtrap (and right now it doesn't run, so I'm not putting you in jeopardy either). Therefore, as the car owner, and even more so since there's been a bunch of competent mechanics who tried to contact the manufacturer and got nowhere, _you_ and every other owner of that model need to be the ones contacting the manufacturer ASAP, to get that issue properly fixed, and send them a clear message that safety issues, even if they may only impact a minority of users, should not be ignored. -- the users will be well aware of your attitude and will blame you when their devices don't work, instead of blaming the manufacturer. Which, as exposed above, is fine by me. Better an educated, yet possibly angry, user than one who, because his or her device just works, isn't going to do anything more and allow more users to fare just as bad or even worse. You gotta stop considering what's best for a limited number of individuals, and worst for the group at some stage, and do what's best for the whole group (even if the only way to get the original subset to do what's best for the group is to anger them and have them give in to transient selfishness). I see a very similar phenomenon occuring on a smaller scale all the time in the linux-usb mailing list. When something goes wrong with a USB device, people always report it to the USB mailing list. Quite often it turns out the bug actually belongs to a different subsystem. But it often doesn't get reported on the mailing list for that subsystem, because the USB aspect is the most visible. I'd be tempted to say that it may be because people have seen that you guys were willing to apply workarounds to get their devices to work no matter what. ;) I doubt that such a review would have much impact. Almost all the readers will think I'm not using Linux, so I don't care if the device doesn't work with Linux. This is just another example showing how Linux is inferior to Windows. Once more, I find that pretty dismissive of the ultimate ability of people to comprehend current and far reaching issues. A much better approach would be: This device is not compliant with the USB spec and doesn't deserve to carry the USB logo. Even that might not hold much weight; a lot of people will care only about whether the device works, not how well it follows the spec. That's actually
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.05 15:53, Alan Stern wrote: The line is clear as can be. Problematic requests created by the user's program are the user's fault and can be fixed by the user (or the program author -- at any rate, they aren't libusb's fault). Problematic requests created autonomously by libusb _are_ libusb's fault. Fair enough. And thanks for the examples, as they do help getting a clearer picture (Dongles are a good examples, as manufacturers will of course be quite paranoid about firmware updates). The reasoning is simple: Linux does its best to work with existing hardware, even when the hardware is not spec-compliant. Eventually there may come a point where a device is too unreasonable to deal with, but we try to push that as far off as possible. After all, if these devices work with Windows then they should work with Linux. As a Windows developer, and seeing that Microsoft's history is paved with both 180 degrees turns (except perhaps when it comes to maintaining 30 year old backwards compatibility) and oftentimes disdain for following specs they can't exert control on, I can't help but feel concerned about kernel developers pointing to Windows as something they want to follow, be it only with regards to device support... ;) For USB, a good rule of thumb is: Any request not sent by Windows XP will crash some device, somewhere. I'm genuinely trying to wrap my head around why you wouldn't want to just tell the device manufacturer it's your problem - fix it, as I The people we deal with are users, not manufacturers. As a general rule, the manufacturers don't listen to us. Yeah. And THAT needs to change. Everybody is sick and tired of getting subpar FLOSS support from manufacturers, and that includes Linus (cf. nVidia). So what are you gonna do? If trying to ask the worst offenders to play nice didn't work, maybe a more aggressive approach needs to be devised... They may listen to customers who buy millions of units, and they may listen to Microsoft, but very few of them listen to Linux kernel developers. With the advent of online purchases that feature prominent user reviews, they may also listen to consumers who post bad reviews of their products, be it only to point out that a device doesn't work on Linux. A single bad review that is backed up by facts (this device doesn't work on Linux because it doesn't respects the USB specs) can have a lot more impact that tens of good ones... I also think that Linux is past the point where it can be dismissed as a fringe OS; one than can be safely be ignored by manufacturers. Microsoft appears on the decline, and Android seems to be on the rise. That oughta count for something as far as Linux is concerned. That kind of attitude doesn't work out in the real world. Not exactly. The kind of attitude that goes against established rules certainly does tend to face an uphill battle, and will often dismissed as unachievable at first (this is a pious dream, but it'll never work out in the real world), since it may require established traditions to be questioned: Why would anyone allow their code or software to be duplicated freely, when they could make royalties from it instead?. How on earth can my business benefit, if I need to spend extra to satisfy 1% or less of my potential users? Yet, it's by ensuring that the idea, and, in the light of it, the shortcomings of the currently accepted alternative, get considered and talked about by the largest number of people, that progress can eventually be obtained in the real world. When complacency is at play, you may have little other choice but to ensure that people are confronted first hand with the shortcomings of the incumbent, so that the greatest number will push for action at the source. It only leads to people ignoring you. You can afford to do that sort of thing if you have Microsoft's clout, but not when your user base is less than 1% of the total. Sorry, but it's not a matter of power. It's a matter of principle and trying to change society, or in this case, the IT and hardware manufacturing landscape, for the better. If, in any situation, only the powerful get to be acknowledged, then by all means, action needs to be taken to change that. We do it so that people can use the devices they already own. (It's not unusual for a quirk to be written by somebody who owns one of the devices it affects.) Yet that only encourages maintaining status-quo (Microsoft or someone else dictates, Linux follows). You may accept this as the best achievable under the current conditions, but I don't think I'll ever be ready for that. Call me idealist, but that's not the kind of world I want to live in. As long as no one asks for change, nothing will ever change. Regards, /Pete -- Get your SQL database under version control now! Version control is standard for application code,
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.04 07:41, Hans de Goede wrote: I believe the discussion between you and Alan has hopefully made it clear why this is a bad idea. Not in the slightest. It's not because something is difficult to accomplish (i.e. may require _workarounds_ for flaky devices) that it's a bad idea. Caching all the basic controllers that we expect the OS to query by default, by duplicating the requests, is essentially a good idea as it avoids unnecessary transfers down the line at times when the running app will not want/expect to be polluted. And as far as I can see, the one issue with this proposal (besides how long it may take us to implement it, which is a genuine concern, but still irrelevant to its technical merits) has everything to do with having to deal with devices that aren't following the USB specs. Well, to me, that's be a bit like saying that trying to provide medical aid to populations in a conflict/disaster zone is a bad idea, because there's the chance that some medical staff will get hurt. If you can factor-in the risks, the benefit of providing help is still greater. Any other solution here means that transfers are at the mercy of someone doing something as basic as reading a descriptor, that by all means the OS should have cached already, and disrupt the bus for no good reason. Thus, unless we expect descriptors to change on a whim, tailgating the OS on the descriptors it is bound to retrieve (device, conf, basic strings) has to be something we'd want to have. That's not to say it may not be difficult/time consuming to implement, but in the absolute, this is what would be best for our users, as anything else will result in *avoidable* bus transfers at a time where they have a very good chance to be disruptive. I've the feeling we're deviating a bit from the original topic. Probably. I'm nowhere near being able to propose something that can help, and I suspect you want a solution soon(ish), and not in one year's time or more. So, while you'll keep hearing me vehemently defending the descriptor tailgating proposal (that is until I see a convincing technical argument as to why this isn't something that would be best for our users, if done properly), I'm not going to oppose the implementation of whatever suits you for the time being either... as long as it isn't something too Linux specific. All I've tried to do is respond to your view that the technical proposal I advocated as the best solution was flawed. If instead of NACK you'd just said This would take too long to implement properly, and I need something I can work with now, we wouldn't be having this discussion. ;) So I agree with you that doing on-demand (not on-enumeration, but on-demand), caching of various descriptors would be a good idea, and then we don't need to add special cached versions of various functions to our API, which would be good. Works as a half solution. But we can do better. But the problem with using a transparent caching approach (which I like as an idea) for the string descriptors I'm interested in, is that our current libusb_get_string_descriptor functions take a device_handle rather then just a device. And getting a device_handle requires privileges under Linux, so what I would like to see is a new set of string descriptor functions which take a device rather then a device_handle as argument. Which is actually fine by me, and not something that I tried to dispute, as implementing the proper caching I envision will take a lot more effort and time. Regards, /Pete -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.04 07:46, Hans de Goede wrote: So I may be misremembering things, as the data we seem to derive from the first IOCTL isn't used for the topology, but to cache the actual config descriptor (which libusb mandates us to cache) and it looks like it's really a matter of caching our descriptors on Windows after all. Interesting, I think it indeed would be a good idea to have an ondemand caching of the config descriptors, so do not do the IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION ioctl until an app actually asks for the relevant info, I know that currently our documentation says: * Get a USB configuration descriptor based on its index. * This is a non-blocking function which does not involve any requests being * sent to the device. But we could change it to say that on some platforms this function may block the first time it is called for a device, and that only subsequent calls are guaranteed to be non-blocking. This is not an API / ABI change, so I see no problem with doing things this way. I'm actually with you there, as I also see this as the best compromise for the time being. My only concern is with app developers who may be relying on cached/nonblocking, but I guess there's only one way to find out if it's a valid concern... For starters we could this just inside libusb, without adding the global daemon / service for caching it. Considering that we've had people very annoyed by those config requests every time we do enum on Windows, I think we definitely want to try to start with this. But if you prefer to directly go all the way that would be fine with me too. I still have Windows/hotplug and plenty of other niceties to take care of, so a formal server proposal is a very very long way off, especially as, if we can avoid these config requests in most common cases, and our users accept that initial descriptor requests may produce transfers, it will become more of a nice-to-have than a must have. Regards, /Pete -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.04 15:33, Alan Stern wrote: So, provided this is all we'd need to do to avoid pollution on Windows, your preference would be for libusb to cancel its established contract (I think it's explicitly documented) to cache the config descriptors on all platforms? Not at all. As I said above, the server should cache whatever it needs. If config descriptors are part of the established contract then the server needs them. I was talking about a non-service implementation (i.e. modifying what we have right now). But I guess that's part of what Hans discussed. BTW, you'd be amazed at how much trouble you can get into merely by trying to send standard requests that try to duplicate what the OS does anyway. And you'd be amazed at the hoops an OS has to jump through to get reasonable data without upsetting devices. Ths OS can't afford the luxury of crashing a device merely because that device fails to comply with the USB spec. Then I'd be tempted to say that what applies to the kernel doesn't necessarily have to apply to a userland library... ;) True. But do you look forward to telling users: Libusb doesn't work with your device because it crashes when we send it this request for information which we don't really need? Well, considering that we're not applying any quirks when a user tries to replicate a sequence of transfers that the kernel may have quirks for, I'd say that, right now, libusb's policy is already to let flaky devices crash... Granted, the difference is that, in this case, this wouldn't be something produced by libusb itself, so we can just blame the user (Don't do that!). But the line between the two looks a bit blurry as far as I'm concerned. And maybe there are quirks that we would actually be better off trying to apply in libusb right now... I'm also curious about these problematic devices you have quirks for. Do you have typical examples of such devices, and what behaviour prompted these? And, more importantly, what's the reasoning behind the kernel not just wanting to let them crash and burn, if the issue was a poor implementation of the specs? I'm genuinely trying to wrap my head around why you wouldn't want to just tell the device manufacturer it's your problem - fix it, as I don't really see anything but a short term goals there, that may end up hurting users more in the long run, such as: - Device has a ROM or can't be updated from a software app = Well, personally, I don't see why anyone wouldn't want to rid the world of such devices once and for all. Reported vulnerabilities won't ever be fixed by the manufacturer and even more importantly, these devices have no means of being repurposed by their users as they see fit. IMO, any smart hardware that executes code that users cannot alter is really a loss for the community, so the more we do to try to rid the world of such devices, the better. - Manufacturer considers the device as discontinued/doesn't want to allocate devs to fix issues = similar story. Telling consumers that hardware has an arbitrary expiration date is practice that must be discouraged when important bugfixes are at play, and the manufacturer has the resources to fix them. Now if the manufacturer is out of business, or too broke, that's a different story, but considering it's not that dissimilar to a vulnerability not getting fixed, it's a very good opportunity to educate consumers on why they should try to avoid hardware that runs closed source. - Fear that users will have a poor impression of Linux if the same hardware works OK on Windows or OS X = Again, not playing in Linux's favour in the long run, because it basically tells manufacturers that it's perfectly fine to ignore Linux altogether. So I have to wonder: What am I missing? What is the reason that pushes you guys to add quirks for flaky devices in the kernel? Regards, /Pete -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.03 16:41, Hans de Goede wrote: So, how could we solve 12 once and for all? Simple, we add an extra layer to libusbx that does user-side caching of all the descriptors we need, and tie this caching, along with enumeration, to the newly added hotplug functionality: whenever a device is plugged in, we get libusbx to issue a bunch of calls similar to the ones the OS issues, to fetch the descriptors we are interested in caching (which may result in doubling bus transfers, but unless you're low speed, this will hardly be an issue: on any device plug in, you should expect to have transfers that you have no control on from the OS anyway, so whether these calls are doubled is hardly something to cry foul over). Strong NACK, we really do not want to do any IO on enumeration at all. USB devices tend to be cheap crap, and various operating systems go out of there way to not upset the cheap crap, ie the Linux kernels uses quite large quirklists for this because some devices crash if you try to get string descriptors. And the idea here is to duplicate what the OS does. If the OS uses quirk lists, which I assume are public, then there's no reason we can't do that too, though I have to wonder how other OSes fare in that matter... Or we just let whatever crash, i.e. Don't plug cheap known problematic crap and expect stability. Either way is no big deal IMO. Really doing any IO at all on enumeration is a big no no. The proposal is simply about duplicating the IO we expect the OS to perform naturally, and no matter what you are trying to pretend, you are NOT going to disturb an app any more than the OS will do by duplicating these basic requests within a reasonable timeframe. No matter how you look at it, it wouldn't be more disruptive as the expected disruption naturally brought by the plugging of a new device on an OS that does descriptor caching. If you don't want lowest common denominator, then that's what you have to do. So I can't help but shake the idea that your proposal is all about: Linux is fine, and I can get what I want there. Why should I have to care about other platforms? Well, libusb is a cross platform library. Focusing on adding calls that are designed specifically with one type of platform in mind (detach kernel anyone?) is something that we should avoid. I guess some of our backends my be already doing some io on enumeration, but we certainly don't need more of it, Why? Because you say so? You have no control over how much IO the OS will do, so how can you confidently say that something that's at the mercy of being doubled with a mere OS update is OK (because it's done by the OS), but something that's doubled by libusb is not? and we certainly don't want to go and do various probing of devices by default. And how's that different from what the OS does exactly? Do you have an estimate of how disruptive you think it will be, outside of brandishing the spectre of extra IO (when it really is duplicated IO within a reasonable timeframe following a device's arrival)? The only point I really get from above is I don't want that. Whenever any device is plugged in, IO will occur. The OS will fetch descriptors. And, outside of Linux, you hardly have any control about what the OS will poke. Well, we've long ceased to try building a library that's meant to cater only for Linux, so IO that you have no control upon on device plug-in is a given with regards to our actual OS landscape. Ergo, having libusb duplicating the expected descriptor caching IO from an OS, within a second (probably much less) of the device being plugged in shouldn't be an issue. You plug a device. You get IO. If you don't want IO, don't plug anything. Whether the IO is duplicated is actually irrelevant as long as the transfers are minimal (they are - we're just fetching descriptors) and occur as soon as the OS lets us do them once device arrival has been advertised. sigh I guess I'll have to demonstrate that this is really the only way to go, with a proposal, to actually convince the world and stop having to shoot down all these fallacious arguments about how libusb mimicking standard OS descriptor caching is going to mean the demise of everything else. Oh well, it's number 3 in my If only I had more time section [1]. I'm still hoping to get there some day... Regards, /Pete [1] https://github.com/pbatard/libwdi/wiki/Backlog -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.03 21:18, Alan Stern wrote: I agree with Hans. In-library caching should be done on-demand, not whenever a new device is enumerated. If the program asks the library for a string descriptor, the back end can get the descriptor from the OS's cache, if one is available. Or it can talk to the device. That's up to the back end. But if the program doesn't ask for a string descriptor, the library shouldn't go out of its way to read it. I guess I need to get back to exposing the original problem we want to solve, and where one byproduct of the proposed solution is that we could implement easy caching of descriptors across all platforms. In the absolute, I agree with you. We shouldn't go out of our way to cache descriptors unless they are already cached by the OS, especially if having 2 different applications doing the caching means repeated IO calls for the same data. But the matter is, in order to solve something not directly related, we're going to have to implement a process that is actually well suited for caching. So, if the idea is that we want to provide consistent descriptor caching across platforms, we might as well use that. But first let me get back to the issue we're going to have to solve. One of the major problems we have on Windows is that we can't build libusb-compliant enumeration information without requesting some data from the parent hub of each device we enumerate. Unfortunately, this ALWAYS sends a formal descriptor query to the device (for the device descriptor if I remember correctly). And since it's Windows, I can't go heckle the guy in charge of the USB stack implementation there, to try to fix this... ;) So (with the current libusb/Windows) every time we (re)enumerate, we get an IO request sent to pretty much every device, as we try to figure out how they are related to one another in order to return up to date enum data to the user. Ouch! This is of course quite disruptive and something we want to avoid if we can (some people are very unhappy about this, and have proposed simply dropping the idea of building any form of topology on Windows). You may have a libusb app doing ISOC or something and all it takes is another app simply getting the list of USB devices, to get polluting descriptor requests all over the bus. Again, none of this has anything to do with trying to cache descriptors. Even if you have hotplug, and set your enum process to only update the data it needs according to the device insert/removal notification, as long as the updated enum data isn't shared across all libusb apps, it just takes another app issuing its first enum to disrupt your bus. So, to work around this, at least on Windows, we're going to have to implement some sort of centralized process, that will act as the sole point of entry for communications with the OS for device insertion/removal, and that will serve up-to-date libusb enum data to any libusb apps running on the system. This way we can ensure that enum, and it's bus polluting IO, is limited and only occurs once for the inserted device. Well, if we have that layer on Windows, which basically duplicates what we'd like the OS to provide without having to send IO on the bus, we might as well make that common to all OSes and use it to piggypack on the IO that is going to occur from the OS on device insertion, to cache actual descriptor data while we're at it. This way, we can provide a consistent experience with regards to descriptor caching, and make apps portable. Now, we may not want to cache all descriptors (In the original mail, I mentioned that we only wanted to cache the ones that we think our users will request most, something that can start small, and that we can fine tune as we go along), but at the very least, I think that if we have a centralized hotplug/enum process above, we might as well use it to cache the basic descriptors that are queried by the OS on insertion. All it'll do is duplicate IO calls that are bound to occur from the OS no matter what. Therefore, existing devices and bus transfers should be no more troubled by a few extra similar transfers than by the ones that were issued just before by the OS. As long as we only get one set of duplicated calls, for all libusb apps and for all users, and limited to device insertion, I don't see this basic OS-independent caching being that much of an issue (but yeah, it will take some work to get there). Regards, /Pete -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ libusbx-devel mailing list
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
On 2013.08.04 00:51, Alan Stern wrote: Out of curiosity, what data do you need to request from the parent hub? Now that I've looked a bit through old e-mails, it seems that these are config descriptors, coming from a Windows IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION request. I'll have to re-check what goes on the bus though, as we also have an IOCTL_USB_GET_NODE_CONNECTION_INFORMATION elsewhere (which provides us data such as the device connection speed). So I may be misremembering things, as the data we seem to derive from the first IOCTL isn't used for the topology, but to cache the actual config descriptor (which libusb mandates us to cache) and it looks like it's really a matter of caching our descriptors on Windows after all. And why does requesting that data send a query to the child device for its device descriptor? I guess that Microsoft decided that their IOCTL for the config desc should always translate as a bus request. And there is no API call I know of that would allow us to get cached data for those during enum. That seems reasonable. How does this central server process get established? Will libusbx fork a new process to do the work if it can't contact an existing server? That's how I'd see it. What happens if two libusbx instances try to start a new central server at the same time? At least on Windows, you can get global named mutexes. And this is a fairly common problem to solve. The trickiest part, IMO, will be if the API of that process/server changes, as we may need 2 different versions of the library with 2 separate server processes running, to meet their needs. And even for non API breakage, there may be process restart required to always have the most up to date version running (bugfix, etc), still in case we have 2 different versions of the library running. Could be a bit tricky, but that's something we discussed in the past. If you plan for it, it's addressable. This is where I (and probably Hans) disagree. The central server should cache whatever it needs and -- on demand -- whatever clients ask for. Nothing more, unless the server's back end can get the data directly from the OS without any USB traffic. I simply see no point in polluting the bus to get data that a client _might_ want. So, provided this is all we'd need to do to avoid pollution on Windows, your preference would be for libusb to cancel its established contract (I think it's explicitly documented) to cache the config descriptors on all platforms? BTW, you'd be amazed at how much trouble you can get into merely by trying to send standard requests that try to duplicate what the OS does anyway. And you'd be amazed at the hoops an OS has to jump through to get reasonable data without upsetting devices. Ths OS can't afford the luxury of crashing a device merely because that device fails to comply with the USB spec. Then I'd be tempted to say that what applies to the kernel doesn't necessarily have to apply to a userland library... ;) Regards, /Pete -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Doing a 1.0.17 release
On 2013.07.30 20:24, Nathan Hjelm wrote: The only candidates which I see for 1.0.17 are Sean McBride's fixes, and then esp. the xcode project file fix. But I'll leave that up to Nathan. There would also be the Windows/Android logging fixes proposed by Toby, but I'm supposed to review that, and I'm still not sure when I'll get a chance to properly do it, i.e. don't let that hold you back. I see nothing wrong with adding an XCode project. I cherry-picked the changes out of Sean's repository and will push them shortly. Thanks. Also, I have a branch in my libusbx repository with all relevant references to libusbx have been changed to libusb. Great. That's something I was planning to do (and I'm glad to see I won't have to!). I will keep this branch in sync with the master. When do we want to make the official switch? 1.0.18? There will be some more Windows related changes related to the libusbx - libusb switchback (solution files need to be renamed), and I think it would be better if we did the switch to libusb by the time we have a libusb github repo ready, so I'd prefer not to try to rush it for the 1.0.17 release. Else we're going to have pieces that direct people to the libusbx-devel mailing list, others to libusb-devel, same for the websites, and it will be more confusing for our users than anything else. Some people are already complaining that we provided too few bits and piece of information about the merge, so I'd prefer if all the merge steps occurred within a single release, where we can point to all the finalized pieces at once. Else we may get more complaints. By the way, since my understanding is that you were the one who modified the libusb.org downloads, can you please add a note about the merging as requested by https://github.com/libusbx/libusbx/issues/123#issuecomment-21789151? Regards, /Pete -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH v2 2/2] Windows: Make ENABLE_DEBUG_LOGGING enable logging output to the debugger.
On 2013.07.23 11:33, Toby Gray wrote: Yes I have. It was one of those bits of work that when I started looking at it I discovered several other things which were wrong. I send a series of patches, including the new config option, syslog support and Android support in the mail titled Improved log in non-console applications and Android on 9th July. My bad. Would it be possible to get the following three small fixes into master before the next release? OK, then I guess I'll have to look at these Windows patches sooner than I was planning to... ;) Regards, /Pete -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Update website and documentation to reflect libusb and libusb merge (#123)
Please be mindful that the merging is far from complete. What you've seen is basically the second step (the announcement that the projects would merge was the first one), and we are planning to update the content to reflect this, but this is a **slow** process (there's a lot more than just updating the websites - for instance all the libusbx references in source need to be updated, we need to setup and advertise a single point of entries for git, bug tracker, etc.) and it will likely take months to complete it. So, in essence, libusb and libusbx have not merged yet. The process has only just started. And that is the reason why we think it will be less confusing for our users to keep the projects as if they were separate for the time being (else, users may have no idea where they should go to report bugs, look for old releases, etc.) even more so as we are planning to move/rename the libusbx github repository into a libusb one, so it wouldn't make much sense to point libusb users to something that is going to disappear. Now, the reason the libusbx source tarballs are linked on the main libusb page is that we want to provide libusb users with a release that has the latest updates and features (such as hotplug), so this was updated as a matter or priority... For the time being, can we please ask you to be patient? We will provide ample information on the merging process in due time. But we do need a few more things to be finalized before we can do that. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/123#issuecomment-21436684 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Update shared library version to indicated that new APIs were added (#122)
This was ignored because libtool versioning doesn't work that great for a cross platform library that can produce a Windows DLL (especially if compiled from MSVC where none of what is declared in `configure.ac` applies). The preferred way of checking for incompatibilities is to use [`LIBUSBX_API_VERSION`](http://libusbx.sourceforge.net/api-1.0/group__misc.html#gaa83ecded256e0767220bcc21cc92365d) in your application code. As you will see with the [hotplug calls](http://libusbx.sourceforge.net/api-1.0/group__hotplug.html#ga4868157346bbf2c70b6af0cb0a6c0094), we do try to document the minimal `LIBUSBX_API` version to use for new API calls. Granted, this is not as convenient as letting libtool do it, but unless you know of a good way to handle a cross-platform API versioning, that doesn't leave Windows out, I'm not sure we want to multiply the versioning numbers we need to alter, as I'm pretty sure we're going to forget to keep them in sync. Now, another solution would be to only update the `configure.ac` version and then use a script that converts this version to a `LIBUSBX_API_VERSION` number (or do the opposite and update `configure.ac` from `LIBUSBX_API_VERSION`). I sure wouldn't mind hearing what other people think... --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/pull/122#issuecomment-21438842 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH v2 2/2] Windows: Make ENABLE_DEBUG_LOGGING enable logging output to the debugger.
Hi Toby, Do you have plans to look into adding a new config option for sending the debug output to the debugger, or do you want me to look into it? Regards, /Pete PS: I'm not forgetting about your other Windows patches, but it may be some time before I get back to you on that. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Mac OSX: libusbx crashes when unplugging a device (1.0.16) (#121)
I would vote to release an RC rather than a full blown release on account that: 1. People who want a release should be able to use the RC just as well (plus if it can get our users into the habit of actually testing RCs rather than wait for the release, so that we identify these kind of bugs before then, that wouldn't be a bad thing) 2. We're picking a few two many issues here, and I'd rather see the next release address them all and avoid creating new ones. 3. I'd be more comfortable if Hans had a chance to look at the proposals, and going RC until Hans is back seems like an effective way to achieve that. 4. Since I'm planning to keep my involvement with libusbx at a minimal level over the coming weeks (Rufus) I wouldn't mind having Nathan handling the libusbx release process... but with the safety net that an RC provides. Does that sound OK? Or do we think that an RC won't be enough to compensate for a bugfix release ASAP? --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/121#issuecomment-21374250 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] hotplug: Pass explicit context to callbacks
On 2013.07.12 14:10, Florian Albrechtskirchinger wrote: --- a/libusb/hotplug.c +++ b/libusb/hotplug.c @@ -167,8 +167,7 @@ static int usbi_hotplug_match_cb (struct libusb_context *ctx, return 0; } - return hotplug_cb-cb (ctx == usbi_default_context ? NULL : ctx, -dev, event, hotplug_cb-user_data); + return hotplug_cb-cb (ctx, dev, event, hotplug_cb-user_data); } I don't see a reason not to use the default context either. It's supposed to work in the absence of a user specified context. Unless someone has any objection, I'm planning to push this patch tomorrow. Regards, /Pete -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Releasing 1.0.16 ...
On 2013.07.09 14:51, Hans de Goede wrote: Headsup: unless there are any objections I plan to release 1.0.16 coming Thursday. Sounds good to me. Make sure the milestone is updated if that's not already the case. If needed, I can upload the doc on release day. Regards, /Pete -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Documentation: topology call documentation improvement (#95)
Closed #95 via b4c18fac65a594502eec5edd2611d5953e7950f7. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/95 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] Documentation: topology call documentation improvement (#95)
This is a test - please ignore. --- Reply to this email directly or view it on GitHub: https://github.com/libusbx/libusbx/issues/95#issuecomment-20487661 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] libusb_get_device_descriptor: Document this now always succeeds
I have now merged this patch with my previous doc one, and pushed it. Also, thanks to a suggestion from Nathan, you may now see some github notifications with regards to libusbx issues (at least, they seem to appear on the mailing list archive [1], though I don't get them in my libusbx inbox for some reason). Regards, /Pete [1] http://sourceforge.net/mailarchive/forum.php?forum_name=libusbx-develmax_rows=25style=ultimateviewmonth=201307 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [Patches for 1.0.16 0/2]: Allow hotplug users to wakeup handle_events
On Thursday, July 4, 2013, Hans de Goede wrote: Given that without this patch the hotplug API is essentially unusable for applications with a separate event thread, I believe we should add this to 1.0.16. Agreed. It is not terribly adventurous, but I think it would be best to also do an 1.0.16rc3 with this in, and delay the actual release by a few days. Also agreed. The patch doesn't look terribly risky, but playing it safe is preferable. If I can get an ack for this by tomorrow, I can do 1.0.16rc3 tomorrow, so people can test over the weekend. Ack from me, though, considering that we already have 2 people who ran into that issue, maybe we'd want to document how an app with a separate event thread is supposed to exit in a safe manner (basically adding the snippets of code you pointed out somewhere in our doc). Regards, /Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Improved logging v2
On 2013.07.01 11:07, Hans de Goede wrote: I won't be working on issue #95, so unless someone else does it, it is going to get moved to the next release. I'll try to have a stab at it this week, since it's the no-impact kind of stuff that can happen right before release. Regards, /Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH v2 2/2] Windows: Make ENABLE_DEBUG_LOGGING enable logging output to the debugger.
On 2013.06.27 14:49, Toby Gray wrote: This change makes it considerably easier to debug issues in UI applications which don't necessarily have a console connected to stderr. I like that idea. That's something I've been using for Rufus, and it can come quite handy for pure GUI apps indeed. Outputting to the debugger shouldn't occur in normal situations so this change has to be explicitly enabled by a build-time config flag. I guess that makes sense, since UI apps wouldn't have commandline parameters to toggle the option, and using a global variable wouldn't be of much use either. However, I don't think hijacking ENABLE_DEBUG_LOGGING is the way to go. Some people may still want to use ENABLE_DEBUG_LOGGING to force debug logging to the console on Windows, and we would break the behaviour of any app that was configured with that. I'd go for USE_OS_LOGGING_FACILITY or something, and a configure option in the same vein to make it as explicit as possible what the intent is here, especially as some people may only want error and warnings, and not debug, to be directed to the OS logging facility. And of course, this may also make it more suitable for other OSes to implement a similar option (eg. direct output to one of the log facilities on Linux). Regards, /Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Improved logging v2
On 2013.06.30 08:58, Ludovic Rousseau wrote: 2013/6/27 Tim Roberts t...@probo.com: This is micro-optimization, of course, but it would be more efficient to do this instead: fputs(str, stderr); I also agree. Maybe Pete missed your email. Oops, my bad. Apologies to Tim for missing his mail, and thanks to Ludovic for the patch. While I'd expect most compilers to be smart enough to make these kind of optimizations, I have now applied and pushed it, under Tim's name, since he's the one who proposed the change. Regards, /Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Improved logging v2
https://github.com/libusbx/libusbx/commit/7b893cc7cee185c0bf771166ca61a05b32800556 should now fix the cywgin issue, as well as sort our gettimeofday() usage for all the Windows compilers. It also includes the missing %s reported earlier. The issue really was that __GCC__ never existed in the first place, even for MinGW, and we should have used __GNUC__ all along instead. I tested compilation for all of MSVC/WDK/MinGW(32/64/Clang)/cywgin and everything looks good now. While I was at it, I increased the buffer size to 1024 (we have some crazy long strings for the USB ids on Windows, and I feel that 256 bytes might be two small if we ever try to print 2 of them), and fixed some whitespace/quotes issues that had been bothering me. Once more, given the amount of changes that have been pushed since RC1, I would strongly suggest that we declare RC2 and push the 1.0.16 milestone (due tomorrow [1]) by one week (which may give us a chance to sort out #95 [2] that is still open against 1.0.16). Regards, /Pete [1] https://github.com/libusbx/libusbx/issues/milestones [2] https://github.com/libusbx/libusbx/issues/95 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Revert: Core: Don't wait for completion if cancel_transfer failed ?
On 2013.06.20 12:11, Hans de Goede wrote: Done (more or less, see git). Even with the dual set of patches, I'm still not sure we wouldn't want to at least print a debug message if we find out that libusb_cancel_transfer(...) failed. But I guess we can go with the current proposal. On a side note, I'd very much prefer a cool-off period of at least one day between the last non-minor commit being pushed and RC (the patches you pushed against sync.c don't look that minor to me). I know we're all in a hurry to get RC off the ground, but I've had too many bad surprises from seemingly innocuous fixes breaking Windows, and I can't help getting nervous seeing something flagged as RC before it has been tested on all the Windows platforms. This being said, I have just re-run the usual set of VS2012+Code Analysis, MinGW-Clang, cygwin, WDK (also threw in MinGW-w64 for good measure) and things look OK as far as compilation is concerned. Regards, /Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Announcing libusbx-1.0.16-rc1
With regards to https://github.com/libusbx/libusbx/commit/e2fe75ebab83d2fe8ee8ebc3ff13fef0132bff18 - Martin and Michael are in the list of major contributors in the AUTHORS header (the ones that have a copyright note), and the convention is that we don't duplicate people who are already listed there. - You missed recent contributors Chris Dickens, Colin Walters, Ilya Konstantinov and Luca Longinotti For the record, what I usually do here is 'git shortlog -s | cut -c8- AUTHORS' and then massage the git diff. I have now pushed a fix for the AUTHORS file. I'll try to push Windows binaries for the RC within an hour or so. Regards, /Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Revert: Core: Don't wait for completion if cancel_transfer failed ?
NB: The original issue we're talking about here is #76: https://github.com/libusbx/libusbx/issues/76 On 2013.06.19 11:51, Hans de Goede wrote: And I noticed that this patch seems wrong, if the cancel fails it does not wait but it still frees the transfer, which at that point is still referenced by the underlying urb, which has potentially not completed yet. No good indeed. I see 2 options to move forward with this: 1) Keep the patch, but if the cancel fails do not free the transfer, this is not really helpful, since the app could still kill the buffer the transfer references after we return. 2) Revert the patch, and re-open https://github.com/libusbx/libusbx/issues/76 Asking the user for source for the app in question, and hunt down the real bug there. May vote goes to 2, input much appreciated (iow please give me your 2 cents) ? I think at the very least, if we go with 2, we want to check the return code from libusb_cancel_transfer(transfer) and produce a warning if it's not SUCCESS. This should at least give some insight to app developers as to what is going on. Otherwise, no objection to reverting the patch and try to get more data to come up with an alternative. Regards, /Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Core: fix compiler warning in libusb_setlocale()
On 2013.06.19 12:21, Ludovic Rousseau wrote: - int i; + size_t i; Note that this creates a new warning in VS2012 (64 bit), with the usbi_locale = i; line, due usbi_locale being defined as an int: 1 ..\libusb\strerror.c(156): warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data I'll be pushing a fix for the fix shortly, that switches usbi_locale to size_t, as this looks like the better choice compared with a cast to int. Hopefully, there won't be a 3rd fix... ;) Regards, /Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
