rather than the requested transfer length (USBD_SHORT_XFER_OK is
set, so this may happen). This is the documented behaviour, and it is
appearently what the Linux version does. Bump PKGREVISION. From
Erik Berls per PR pkg/37053.
Fix structure padding issues on some architectures
Fix compile warnings with newer versions of gcc
Fix memory leak when continuously rescanning for devices
Check for device nodes in /dev/usb under Linux
Fix compile problem with Darwin/Mac OS X port
Add support for Darwin/Mac OS X 10.4
Fix error when transactions are aborted
Requery endpoints when switching alternate settings
Support more BSD based distributions
Fix problem with short control messages in BSD port
Various other minor fixes
* Fix various compile warnings
* Require newer autotools
* Switch from QT to STL for C++ extensions
* Linux:
* Speed up small bulk and interrupt transfers to previous speeds
* Fix case where bulk and interrupt transfers could block forever
* Fix tree heirarchy building code (undocumented)
New Features:
* Synchronous Interrupt read support.
* Added new usb_get_descriptor_by_endpoint() function. Properly prototyped
existing usb_get_descriptor() function.
* (Linux) Check for usbdevfs in /sys/bus/usb (2.6 kernel).
* (Linux) Added usb_get_driver_np() function to get driver bound to interface.
* (Linux) Added usb_detach_kernel_driver_np() function to detach kernel driver
from interface.
Bug Fixes:
* Many return values are starting to become normalized (consistent across ports)
* Various bug fixes in Darwin port.
* Fix usb_string() to fetch language index correctly.
* More documentation updates and fixes.
Patch from seagull at aracnet.com:
Some time ago, I identified a problem with libusb under FreeBSD. The issue
is that the current implementation of bsd.c assumes that a particular
endpoint is unidirectional. If you write, for example, to endpoint 2,
you can't later on read from that same endpoint and visa-versa. Although
USB pipes are unidrectional, they can be "stacked" on the same endpoint.
Endpoint 2, for example, has two pipes: 0x02 and 0x82, with the high bit
representing the transfer direction of the pipe.
Since the BSD USB stack does not let you open two descriptors for the same
endpoint, and it does not let you close and reopen an endpoint in the middle
of a "session", I had originally proposed that the endpoint always be opened
O_RDWR so that bidirectional communication would be supported.
However, it was later pointed out that a device which really did only have a
unidrectional pipe on an endpoint would fail on ENXIO if you tried to open
it O_RDWR, so I went back to the drawing board and came up with a patch
for bsd.c which should solve the issue for both cases. What it does is
first attempt to open the endpoint O_RDWR. If that fails on ENXIO, then it
attempts to open the pipe in the direction appropriate for the operation
that you were committing.
