Re: [OpenOCD-devel] [libusb] Announcing libusb-1.0.18 (as well as libusbx-1.0.18 *FINAL*)
Hi Jens, On 2014.01.27 12:25, Jens Bauer wrote: On Sun, 26 Jan 2014 17:07:42 +, Pete Batard wrote: I, and many others, happen to think users of libusb deserve more than one release in 4 years, even more so as continuous major development has been going on. I disagree. If libusb works fine, no need to fix bugs that are not present. Shall I remind you that, the only reason people can run OpenOCD on Windows, using libusb (rather than libusbx) is that *we* pushed Peter, through the release of libusbx, to release his version of libusb 1.0.9, that was the first to include Windows support. If you followed his earlier dismissive comments on OpenOCD and elsewhere about the Windows backend being subpar, then you can only come to the logical conclusion that he would probably never have released otherwise (since there hasn't been any other release of libusb until this new one). So, you are basically implying that it was fine for OpenOCD to remain officially unavailable on Windows, until such time Peter felt that the Windows backend was to his liking. But in the same sentence, you also kind of prove my point that, if the Windows backend was as subpar as Peter makes it to be, you couldn't really be saying that libusb works fine for your purpose, since I don't recall seeing much complaint from OpenOCD Windows users on our lists. Furthermore, we also did fix some pretty major bugs since libusb 1.0.9 was released (please take a look at our Changelog). Or are you under the impression that libusb is a lot more stable and much less in need of development and bugfix than OpenOCD? You may have been lucky to never run into a libusb bug when using OpenOCD. But I think the vast majority of OpenOCD and libusb users will prefer relying on actual bug fixes, from an up to date library, rather than luck. If the USB standard does not change, no need to change the library. Ah, but the USB standard did change, and we did add support for a bunch of newly introduced USB 3.0 constructs (BOS, etc). Also, if you are planning to use OpenOCD through an USB 3.0 controller on Windows 7, you very much want to use the latest libusb, as we have to regularly add the names of new HCD root hubs (which each manufacturer provides) into the library. Without this, you can forget about using OpenOCD through an USB 3.0 port. This is very straightforward low risk fix to add (and we actually did one of those in this release - VIA xHCI support). Do you really want to tell Windows 7 users with a VIA USB 3.0 controller, and that want to use OpenOCD to access an FTDI device for instance, that they are MUCH better off waiting a couple of years for a more stable libusb release (whatever that means)? Since libusb is a core library, I find it much more important that it stays reliable. Which is our goal. Contrary to Peter's propaganda, we are committed to fixing, improving, and trying to make libusb more reliable. It looks to me like Peter seems to be under this weird impression that any software development that isn't under his direct control can only be rushed and have complete disregard for stability. But if your idea of stability, when there are very important bug to fix as well as much requested features to add (such as hotplug), is to only release once in 5 years, I think you are mistaking stability for immobility. Each time there is a non-bugfix change to a library, there is a risk of introducing new bugs. Should you advise the cancellation the next release of OpenOCD then? If not, it makes no more sense to be against this release of libusb as it is to be against the next release of OpenOCD. That is, unless you consider that, unlike OpenOCD ones, the current libusb developers and mailing list contributors are just a bunch of amateurs who have little clue on how to develop serious, stable code. But if that is the case, I will kindly ask you to try to back up what made you reach this conclusion with facts, rather than hearsay. I'd personally prefer stable quality code over code that has features added every day. Hyperbole. Disproved below. OpenOCD is a good example; it's been an open wound for a while, but the current developers are very serious and focus on fixing bugs, rather than adding new features. OK, so Peter's propaganda has worked, and you are under the impression that the current libusb development team and contributors are NOT serious, don't care about bugs and just want to add shiny features. If perusing through the libusb-devel and libusbx-devel mailing lists is not enough to prove the opposite, let me show you our Changelog then, for 1.0.17 (libusbx, released 5 months ago) to 1.0.18, and which was linked in the announcement (http://log.libusb.info): 2014-01-25: v1.0.18 * 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
Re: [OpenOCD-devel] [libusb] Announcing libusb-1.0.18 (as well as libusbx-1.0.18 *FINAL*)
On 2014.01.27 20:44, Jens Bauer wrote: Pete, you are young Not a good start. What if I told you I started programming in the mid 80s? Do I still qualify? But you have a problem. You feel attacked whenever anyone says something that you do not agree with. Yes, I tend to be annoyed when people seem to suggest to go against what the majority of our collective users and contributors has regularly expressed they wanted which is: a single libusb, where bugs get fixed on regular basis, and where much requested features, such as hotplug support, do make it into a release. If your suggestion wasn't that it might be for the best if libusb was split into 2 separate projects, again, right after we finally managed to undo the earlier split which the vast majority of all of us (users, contributors, maintainers) would really have preferred to do without, then please clarify. Also, as you should know, most projects, that have the capacity, tend to go around with a development branch and a stable branch, which is actually also something we've been toying about, with a long proposed but yet to be implemented 2.0 branch. How comes you didn't mention something like that? So yeah, I am flabbergasted as to why you would even *remotely* suggest to go back to splitting libusb, especially when your argument appears to boil down to one's subjective perception of stability associated with a name. instead of trying to understand the actual problem You can try to clarify how one is to interpret what you said earlier. Or you can go on a meaningless ad-hominen. Your choice. Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libusb] Announcing libusb-1.0.18 (as well as libusbx-1.0.18 *FINAL*)
On 2014.01.26 07:47, Peter Stuge wrote: I've removed the libusbx-devel list since Pete Batard banned[1] me after I wrote that I considered the libusbx code to have a bug[2]. Here we go again. Well, we've been through that quite a few times already. In the thread you pointed, I explained why this didn't qualify as a bug. A bug is something you don't want to happen that you overlooked whereas this limitation was a conscious design decision, and I explained, twice, why it was in place. In that same thread, I also offered, if you wanted to do something a bit more productive than just jump around and cry bug (as you previously did for items that ranged from alleged issues that someone never got around to report to us, to features that had not been implemented), to submit a patch that would help the user. You chose not to do that, but instead persisted in the unhelpful antics that got you earlier warnings that you could be banned ([1], [2], [3], which are a direct result of a stream of other non-helpful libusbx related posts you made to various mailing lists). So you were banned because it became clear that you weren't using the mailing list as a means of helping users, but as a means of trying to scare them away from the project, as well as undermine it. I do however not think that it was appropriate to give an ultimatum and remove me from the SF project, even if I wasn't responding to emails, even for quite some time. The libusb-devel mailing list, and your own inbox, should be littered with posts from people (not just myself and Nathan), who, for many years, tried to reach a compromise with you, to no avail. As painful as it may be, one has to recognize when the diplomatic solution just isn't working, and when action needs to be taken. I think the decent move would have been to work on libusbx under the name of libusbx. But we're past that. I, and many others, happen to think users of libusb deserve more than one release in 4 years, even more so as continuous major development has been going on. I'll of course continue reading both libusb and libusbx lists, but since Pete and Nathan have made it clear that they don't think I can contribute to what they do I'll continue to work on my own. You are free to provide constructive criticism, by pointing exactly to the section of codes you think have issues, and proposing patches to address them. As we have tried to make clear repeatedly, our objections stem from you not doing these things when pressed to do so. What has in fact happened is that libusbx developers have taken control of the libusb project on SourceForge and, as Pete describes, have now simply renamed libusbx to libusb. That's of course not a merge. That would be true if you could name one active libusb developer that can be counted as being opposed to the merge of libusbx and libusb... But more than anything I can write here, the git history from http://git.libusb.org/?p=libusb.git speaks for itself. What I *will* however do is continue to work with the libusb.org code, website and community, as I have for more than 10 years. And you have all our best wishes with that, really (for that matter, we're not planning to do anything to the old libusb tarballs you are currently linking to, from libusb.org, and that belong to the libusb SF project). Competition is welcome, as long as it produces results that can be used. It doesn't show much, libusb.git hasn't seen commits for a long time and I have many unreplied emails, but I am still here and work is still ongoing, if slowly. There are changes coming to the git repo as well as some kind of release looming. Allow me to quote a post of yours that is very relevant to this discussion then, since this is the very rebuttal you gave when we announced that libusb and libusbx would merge [5]: please hold off on reporting about the future until it has actually happened. It's true that libusbx has bug fixes and new features which aren't yet in the libusb.org code but it's also true that the libusbx code has technical issues caused by bad implementations and bad design, Then, for the last time, please point to them. both of which I don't want to include in the libusb.org git and which I work on removing from libusb.org code in cases where it already exists. Great. If we think you fixed actual bugs, we may pick some of your changes, as we've done in the past. But if it boils down to deciding, on principle, to annoy existing users by removing convenient features that have already been integrated and used, as you have also done in the past, we may pass... there's more than enough bad software in the world already There you go again, trying to covertly qualify libusb/libusbx as bad software without pointing to anything concrete that made you reach such a conclusion. Just to reiterate, this actual name calling of the libusbx project is one of the many reasons you were banned
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-de...@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-de...@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 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
libusbx v1.0.15 has been released
Hi, Libusbx v1.0.15 has now been released. A source tarball is available at: http://sourceforge.net/projects/libusbx/files/releases/1.0.15/source/ This version brings the following fixes and improvements: * Improve transfer cancellation and avoid short read failures on broken descriptors * Filter out 8-bit characters in libusb_get_string_descriptor_ascii() * Add WinCE support * Add library stress tests * Add Cypress FX3 firmware upload support for fxload sample * Add HID and kernel driver detach support capabilities detection * Add SuperSpeed detection on OS X * Fix bInterval value interpretation on OS X * Fix issues with autoclaim, composite HID devices, interface autoclaim and early abort in libusb_close() on Windows. Also add VS2012 solution files. * Improve fd event handling on Linux For more details about the changes that were applied since v1.0.14, refer to the libusbx git log at: https://github.com/libusbx/libusbx/commits/master For additional info, please visit: http://libusbx.org Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On 2013.04.09 11:39, nico wrote: can someone provide a MinGW 32bits built of the last working RC, Sure. Please have a look at the -win download from: https://sourceforge.net/projects/libusbx/files/releases/1.0.15/binaries/ The Windows binary contains the 32 and 64 bit versions of both the static library and DLL, for MSVC and MinGW. In related news, the MSCV DLLs now include the .pdb, as was recently requested. Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On 2013.04.04 09:27, nico wrote: Making all in libusb CC libusb_1_0_la-core.lo core.c:1755:30: warning: use of logical '' with constant operand Thanks for the report, and the test. This is now fixed in RC3, along with a couple minor issues. The new RC is available from: http://sourceforge.net/projects/libusbx/files/releases/1.0.15/source/ Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
libusbx v1.0.15-rc2 is now available for testing
Hi, The 2nd release candidate for libusbx v1.0.15 is now available at http://sourceforge.net/projects/libusbx/files/releases/1.0.15/source/ This version brings the following improvements: * Improve tranfer cancellation and avoid short read failures on broken descriptors * Filter out 8-bit characters in libusb_get_string_descriptor_ascii() * Add WinCE support * Add library stress tests * Add FX3 firmware upload support for fxload * Add HID and kernel driver detach support capabilities detection * Add SuperSpeed detection on OS X * Don't assume an high speed for isochronous or an interval or 1 on OS X * Fix issues with autoclaim, composite HID devices, interface autoclaim and early abort in libusb_close() on Windows. Also add VS 2012 solution files. * Improve fd event handling on Linux * Other bug fixes and improvements For more details, please see the libusbx git log at: https://github.com/libusbx/libusbx/commits/master If you have an application relying on libusb or libusbx, or are a distribution maintainer, you are encouraged to test this RC and report any issues to the libusbx mailing list before the planned release due on 2013.04.14. For more info, please visit http://libusbx.org Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
libusbx-1.0.14 has been released
a.k.a. 1.0.13, we hardly knew ye. * Reverts the previous API change with regards to bMaxPower. * Note that LIBUSBX_API_VERSION is *decreased* to 0x01FF and the previous guidelines with regards to concurrent use of MaxPower/bMaxPower still apply. Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libusbx-1.0.13 has been released
On 2012.09.24 18:24, Greg KH wrote: I don't think so. Remember, usbutils is the _one_ libusb package that everyone has on their system. The fact that the libusbx release wasn't tested with that package makes me wonder how it was tested at all. Greg, We made the conscious decision to potentially break applications in order to stick to the USB specs exactly. We feel that an USB library that doesn't follow the specs to the letter is less trustworthy than one that does, and that keeping an erroneous attribute for historical reason it too much of a risk, as it creates a precedent for acceptable deviation from the specs. If you want a fix for usbutils, I'll send you one. And no, libusbx wasn't tested against usbutils, though it doesn't matter here, since we're not discovering a problem: we did anticipate breakage with software that relied on MaxPower. And by the way, since our testing resources are limited and we have quite a few platforms to support besides Linux, I might as well take this opportunity to ask anyone who think that they could lend a hand improve testing against RCs to join the libusbx mailing list. But the problem really is that libusb (and libusbx prior to v1.0.13) has a typo that makes it deviate from the USB specs, which left uswith 3 choices: 1. leave the typo as is, and say It's fine to deviate from the USB specs for historical reasons, even if we know our descriptor structure is wrong 2. allow both MaxPower and bMaxPower to be used simultaneously, which we explored for a while, through anonymous structs, but decided against, especially as it made part of #1 still apply. 3. Treat the problem as we would treat an errata from the USB specs, and declare the old way of accessing the Max Power attribute erroneous and requiring immediate fixing. To that extent, let me ask you this: if this was a typo from the specs rather than libusb/libusbx, and an errata was issued by the USB committee, would you not want to apply the errata, even if that meant possible breakage of existing apps? Unfortunately, mistakes do happen. We screwed up the header (well, libusb did, but we'll share the blame just as well) because MaxPower should never ever have been used there. Therefore we decided to treat it exactly as we would treat an errata from the specs and fix it by declaring the old way obsolete (though we did keep some provisions to keep using it). And yes, we're sorry about the fact that it can make applications accessing (b)MaxPower break, including prominent ones, but then again, we also expect applications to break when specs erratas are issued and applied. Therefore we considered that applications that are expected to have the flexibility to handle erratas from the specs should have enough flexibility to apply erratas from libusbx. And we also think that erratas should be applied as soon as they are detected. And to have distros start to blame _me_ for usbutils breaking because libusbx changed a field of a structure in stable release cycle (I say stable as I don't think they bumped the .so name of the library, did they?) That's acting pretty rude, don't you think? Bumping to 1.1 was an option we considered (and that I actually would have preferred as well), but decided against it as we saw the fix as very straightforward, and we also tried to made sure it was prominently well documented. We introduced an API_VERSION macro for the sake allowing applications using the newer libusbx to also compile and run against old versions of libusbx or libusb if needed. Once again, please understand that what decides the content of the libusbx library and its header is the USB specs, and if we find a deviation that we can address that's what we'll do. We also made the decision to try doing that sooner, when fewer applications were expected to access MaxPower, as we think it will be even more painful to leave that for later. Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Libusbx-devel] libusbx-1.0.13 has been released
On 2012.09.24 19:50, Greg KH wrote: Please fix this in libusbx, or bump the .so name so that tools can properly know that the API has changed, and that they want to build against the old one. Well, if you leave us no other alternative, then I guess my vote will be for option 2, especially as we have had issues with trying to keep the libusb and libusbx APIs in sync in the past and we are a fork. For the record, we will keep the LIBUSBX_API_VERSION macro in future versions (though we may decrease it in 1.0.14 if we do a revert), therefore the workaround we provide for bMaxPower and 1.0.13 will still work should you want to to apply it _temporarily_ to alleviate the 1.0.13 blowback you seem to be getting. Note that if we release 1.1, we will not be able to ensure compatibility with libusb, when/if libusb releases 1.1, as this will become a pure libusb matter then. Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Libusbx-devel] libusbx-1.0.13 has been released
On 2012.09.24 20:31, Greg KH wrote: No one delivered any such fix, all I got was a bunch of bug reports this morning from the distros saying that usbutils was suddenly broken. That shows that libusbx is really the problem here, and that maybe I shouldn't depend on it anymore. Could you please have a look at the release note that was posted on this list? We did our best to ensure the possibility of breakage featured prominently. The full content of the post is replicated below. Regards, /Pete On 2012.09.20 22:42, Pete Batard wrote: Hi, It with pleasure that I would like to announce the release of libusbx 1.0.13. This version brings the following notable changes: * [MAJOR] Fix a typo in the API with struct libusb_config_descriptor where MaxPower was used instead of bMaxPower, as per the specs. If your application was accessing the MaxPower attribute, and you need to maintain compatibility with libusb or older versions, please see APPENDIX A below. * Fix broken support for the 0.1 - 1.0 libusb-compat layer * Fix unwanted cancellation of pending timeouts as well as major timeout related bugs * Fix handling of HID and composite devices on Windows * Introduce LIBUSBX_API_VERSION macro * Add Cypress FX/FX2 firmware upload sample, based on fxload from http://linux-hotplug.sourceforge.net * Add libusb0 (libusb-win32) and libusbK driver support on Windows. Note that while the drivers allow it, isochronous transfers are not supported yet in libusbx. Also not supported yet is the use of libusb-win32 filter drivers on composite interfaces * Add support for the new get_capabilities ioctl on Linux and avoid unnecessary splitting of bulk transfers * Improve support for newer Intel and Renesas USB 3.0 controllers on Windows * Harmonize the device number for root hubs across platforms * Other bug fixes and improvements Release archives can be obtained from: https://sourceforge.net/projects/libusbx/files/releases/1.0.13/ For more information, please visit: http://libusbx.org Regards, /Pete ~~ APPENDIX A - Maintaining code compatibility with versions of libusb and libusbx that use MaxPower: If you must to maintain compatibility with versions of the library that aren't using the bMaxPower attribute in struct libusb_config_descriptor the recommended way is to use the new LIBUSBX_API_VERSION macro with an #ifdef. For instance, if your code was written as follows: if (dev-config[0].MaxPower 250) Then you should modify it to have: #if defined(LIBUSBX_API_VERSION) (LIBUSBX_API_VERSION = 0x01000100) if (dev-config[0].bMaxPower 250) #else if (dev-config[0].MaxPower 250) #endif ~~ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
libusbx-1.0.13 has been released
Hi, It with pleasure that I would like to announce the release of libusbx 1.0.13. This version brings the following notable changes: * [MAJOR] Fix a typo in the API with struct libusb_config_descriptor where MaxPower was used instead of bMaxPower, as per the specs. If your application was accessing the MaxPower attribute, and you need to maintain compatibility with libusb or older versions, please see APPENDIX A below. * Fix broken support for the 0.1 - 1.0 libusb-compat layer * Fix unwanted cancellation of pending timeouts as well as major timeout related bugs * Fix handling of HID and composite devices on Windows * Introduce LIBUSBX_API_VERSION macro * Add Cypress FX/FX2 firmware upload sample, based on fxload from http://linux-hotplug.sourceforge.net * Add libusb0 (libusb-win32) and libusbK driver support on Windows. Note that while the drivers allow it, isochronous transfers are not supported yet in libusbx. Also not supported yet is the use of libusb-win32 filter drivers on composite interfaces * Add support for the new get_capabilities ioctl on Linux and avoid unnecessary splitting of bulk transfers * Improve support for newer Intel and Renesas USB 3.0 controllers on Windows * Harmonize the device number for root hubs across platforms * Other bug fixes and improvements Release archives can be obtained from: https://sourceforge.net/projects/libusbx/files/releases/1.0.13/ For more information, please visit: http://libusbx.org Regards, /Pete ~~ APPENDIX A - Maintaining code compatibility with versions of libusb and libusbx that use MaxPower: If you must to maintain compatibility with versions of the library that aren't using the bMaxPower attribute in struct libusb_config_descriptor the recommended way is to use the new LIBUSBX_API_VERSION macro with an #ifdef. For instance, if your code was written as follows: if (dev-config[0].MaxPower 250) Then you should modify it to have: #if defined(LIBUSBX_API_VERSION) (LIBUSBX_API_VERSION = 0x01000100) if (dev-config[0].bMaxPower 250) #else if (dev-config[0].MaxPower 250) #endif ~~ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
