I have now pushed the bMaxPower change to mainline. Before I go
1.0.13-rc1 however, I think I'm warming up to the idea of having a macro
in libusb.h, that could be used to uniquely identify API changes.
Basically, I'm thinking of something like:
#define LIBUSBX_API_VERSION 0x01001234
where the first 16 bits would be the major & minor expressed as bytes
(unlikely to require > 256 values and major/minor version changes should
be be linked to an API change), and the lower 16 bits a value that would
be increased every time we commit new changes to the API, eg. when we
add a new call, such as libusb_get_version, or a new enum value, such as
LIBUSB_SET_ISOCH_DELAY, or even if exceptionally decide to alter an
existing property.
Now, this would of course require manual handling (unless we decide to
do something similar to the handling of the version nano and increase
LIBUSBX_API_VERSION on each commit regardless, which we could, as I
doubt we'll get a distance to root on mainline that's ever going to be >
65535 without changing the minor, and this whole thing is really
versioning in disguise anyway), but I think it could help provide some
avenue for our users to:
1) Check if they're using libusbx or libusb on the system (#ifdef
LIBUSBX_API_VERSION - we'll leave nothing or LIBUSB_API_VERSION to libusb)
2a) Check if an API call or value is supposed to be available at
compilation time and 2b) Simplify our user's conundrum with bMaxPower:
#if defined(LIBUSBX_API_VERSION) && (LIBUSBX_API_VERSION >= 0x01000100)
dev->config[0].bMaxPower < 250
#else
dev->config[0].MaxPower < 250
#endif
I believe this is close to what Toby wanted to see us provide.
Otherwise, for the bMaxPower update, my current preferred proposal would
be to have user copy/paste the new libusbx descriptor structure as is,
use that in their app exclusively and then use a cast. This is what I am
currently pointing out to do in the NEWS update.
I'm also attaching the rest of the NEWS update for 1.0.13-rc1, as it
will probably be of interest to you and could use review.
Regards,
/Pete
diff --git "a/D:\\libusbx\\NEWS" "b/D:\\libusbx\\NEWS"
index 16fe072..b997525 100644
--- "a/D:\\libusbx\\NEWS"
+++ "b/D:\\libusbx\\NEWS"
@@ -2,6 +2,24 @@ This file lists notable changes in each release.
For fine grained history, please see the git log at:
http://log.libusbx.org
+2012-09-15: v1.0.13-rc1
+* [MAJOR] Fix a typo in the API with struct libusb_config_descriptor where
+ MaxPower was used instead of bMaxPower, as defined in the specs. If your
+ application was accessing the MaxPower attribute, and you need to maintain
+ compatibility with libusb or older versions, 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 amjor timeout
related bugs
+* Fix handling of HID and composite devices on Windows
+* Add Cypress FX/FX2 firmware upload sample, based fxload from
+ http://linux-hotplug.sourceforge.net
+* Add libusb0 (libusb-win32) and libusbK driver support on Windows. Note that
using
+ the libusb-win32 filter driver with composite member devices is not
supported yet
+* 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 accross platforms
+* Other bug fixes and improvements
+
2012-06-15: v1.0.12
* Fix a potential major regression with pthread on Linux
* Fix missing thread ID from debug log output on cygwin
@@ -91,3 +109,12 @@ http://log.libusbx.org
2008-05-25: v0.9.0 release
* First libusb-1.0 beta release
+
+
+APPENDIX A: Maintaining compatibility with versions of libusb and libusbx that
use MaxPower
+o Option 1:
+ Copy/paste 'struct libusb_config_descriptor' from the latest libusbx's
libusb.h as
+ 'struct libusb_config_descriptor_new' in your application, and use this for
all descriptor
+ variables (with bMaxPower as member). Then, for every calls that takes a
+ libusb_config_descriptor cast to (struct libusb_config_descriptor).
+o Option 2: Use a LIBUSBX_API_VERSION #ifdef?
------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
