Add libusbx-1.0.16-rc3 as an option to test the new upcoming release.
With 1.0.16 libusb and libusbx are merging back together, so the separation doesn't make sense anymore.
The 1.0.16 RCs might give better results on MacOS X, lots of work has gone in the Darwin backend.
Defaults to stable, but just set LIBUSB="beta" in build/common.sh to switch to 1.0.16 RCs.
Change equals/hashCode for IsoPacketDescriptor and related Transfer to use only their pointers to native memory.
This is because two Transfers may be the same on all accounts, but they still are not the same Transfer that's happening.
Also it interfered with removal of Transfers from a list in the callback: Java couldn't clearly distinguish them and started accessing members of some that were already freed, resulting in exceptions.
Furhter, implement toString for IsoPacketDescriptor, Transfer and ControlSetup.
unsigned integers, which is what libusb uses everywhere.
As it was before, there are parts of the library that return bytes & shorts, like the Descriptors (mostly to
be compatible with javax.usb), and others that take and return int, even where an 8 or 16-bit quantity would
be expected by libusb. I suspect this was done to avoid casting and try to side-step the sign-extension
problem with Java as much as possible, but in the end it leads to an API that's inconsistent, that doesn't
express the ranges it can use well (it's an int but in reality only 16 bits for libusb and so on). It also
fails at basic operations in ways you'd not expect because of the above inconsistencies:
if (deviceDescriptor.bDeviceClass() == LibUsb.CLASS_VENDOR_SPEC) { do something; }
will never work, since the constant is an int and the returned short from bDeviceClass() will be cast up to an
int too, but CLASS_VENDOR_SPEC is 0xFF (MSB=1), it will be sign-extended and the comparison will fail always.
There are two solutions I can see here:
A) consistently use int/long everywhere, both input and output. Everything becomes simpler to write, with less
casts, BUT javax.usb compatibility is gone for the Descriptors and it becomes even unclearer what those values
effectively mean and what range they support.
B) restrict the API to use the proper integer sizes as the C API, ie. 8-bit quantities (char, uint8_t, int8_t)
are represented by jbyte, 16-bit by jshort, and all the constants get properly sized too. With this approach
the sizes and ranges are much clearer, comparisons like the above work out-of-the-box, javax.usb compatibility
is maintained for the Descriptors. The downside is more casting and the occasional need to mask off returned
values to kill the sign-extension when you want to use those values as integers (like when printing stuff in
decimal notation).
I chose to try out the approach from B) for now, this commit implements it as explained above.
It requires minimal changes to the javax.usb implementation, just two casts to byte in AbstractDevice.java.
It would be counter-intuitive to have to set negative timeouts in Java to get longer timeouts in C...
Also reorder getVersion() and getStringDescriptorAscii() to their proper places, so they are in the same order
as they appear in the libusbx documentation.
Enable silent building and C99 support.
Enable lots of warnings and don't enable Werror, as there are warnings in libusb.h.
Fix all warnings. Add const to exceptions.
Make it possible to pass null to setDevHandle and setBuffer in Transfer now.
Make sure that returning a new reference always leads to a new Java object being created, else
freeing/unref'ing that one would lead to the reset of the original object too.
Furthermore, ensure that getDevice also increments the reference count, since if you then free it,
which is usual and not forbidden (libusbx docs just tell you are not obligated to unref it), the
reference count would be wrong and lead to a segfault. This way it would lead at most to keeping a
device around, instead of segfaulting. Still, always free your references!!!
Fix submitted to libusbx as pull request #116.
Also fix this inside the Java wrapper, by adding our own refcount (similar to what was in original usb4java,
but allowing multiple calls with the default context), and making the access to said variable thread-safe.
Once libusbx fixes this, the above code can be removed.
This is obviously unexpected and incorrect, yet cannot be fixed by just adding more data on the C side: you'd have to remember the callback object at the very least, which you could in the user_data
field, but you'd have to make it a global reference. Yet, there would be no easy way to later correctly delete that global reference, since to unset the pollfdNotifiers you just pass NULL to the
same function again, and you don't get back any data on what was there before.
The easiest way to fix this was thus to change to a HashMap, Concurrent since access can be from random threads.
The key was chosen to be the Context.hashCode(), as Integer lookup and comparison is fast, and the hashCode depends directly on the contextPointer stored in the Context (which identifies it).
This works for sure on 32bit systems, but I'm still concerned about 64bit systems, where a long would probably make more sense, I need to think about it some more.
Everything is done in Java here as it's much easier and cleaner, since those are only convenience functions/structs.
Byte order conversion is conveniently handled by ByteBuffer too, and using slice() we access the same memory all around.
Added some final keywords to LibUsb and BufferUtils.
Only fill_control/get_control is still outstanding.
getDescriptor() and getStringDescriptor() were removed from native JNI, since they are static inline convenience functions in libusb.h and don't do anything more than calling the appropriate real function.
Klaus Reimer
Luca Longinotti