Detailed Description

The functionality documented below is designed to help with the following operations:

Enumerating the USB devices currently attached to the system

Choosing a device to operate from your software

Opening and closing the chosen device

In a nutshell...

The description below really makes things sound more complicated than they actually are. The following sequence of function calls will be suitable for almost all scenarios and does not require you to have such a deep understanding of the resource management issues:

You opened the device before freeing the list and unreferencing the devices

If you ended up with a handle, you can now proceed to perform I/O on the device.

Devices and device handles

libusb has a concept of a USB device, represented by the libusb_device opaque type. A device represents a USB device that is currently or was previously connected to the system. Using a reference to a device, you can determine certain information about the device (e.g. you can read the descriptor data).

The libusb_get_device_list() function can be used to obtain a list of devices currently connected to the system. This is known as device discovery.

Just because you have a reference to a device does not mean it is necessarily usable. The device may have been unplugged, you may not have permission to operate such device, or another program or driver may be using the device.

When you've found a device that you'd like to operate, you must ask libusb to open the device using the libusb_open() function. Assuming success, libusb then returns you a device handle (a libusb_device_handle pointer). All "real" I/O operations then operate on the handle rather than the original device pointer.

Device discovery and reference counting

Device discovery (i.e. calling libusb_get_device_list()) returns a freshly-allocated list of devices. The list itself must be freed when you are done with it. libusb also needs to know when it is OK to free the contents of the list - the devices themselves.

The order is important - you must not unreference the device before attempting to open it, because unreferencing it may destroy the device.

For convenience, the libusb_free_device_list() function includes a parameter to optionally unreference all the devices in the list before freeing the list itself. This combines steps 3 and 4 above.

As an implementation detail, libusb_open() actually adds a reference to the device in question. This is because the device remains available through the handle via libusb_get_device(). The reference is deleted during libusb_close().

Function Documentation

You are expected to unreference all the devices when you are done with them, and then free the list with libusb_free_device_list(). Note that libusb_free_device_list() can unref all the devices for you. Be careful not to unreference a device you are about to open until after you have opened it.

This return value of this function indicates the number of devices in the resultant list. The list is actually one element larger, as it is NULL-terminated.

Unless the OS does something funky, or you are hot-plugging USB extension cards, the port number returned by this call is usually guaranteed to be uniquely tied to a physical port, meaning that different devices plugged on the same physical port should return the same port number.

But outside of this, there is no guarantee that the port number returned by this call will remain the same, or even match the order in which ports have been numbered by the HUB/HCD manufacturer.

Convenience function to retrieve the wMaxPacketSize value for a particular endpoint in the active device configuration.

This function was originally intended to be of assistance when setting up isochronous transfers, but a design mistake resulted in this function instead. It simply returns the wMaxPacketSize value without considering its contents. If you're dealing with isochronous transfers, you probably want libusb_get_max_iso_packet_size() instead.

Calculate the maximum packet size which a specific endpoint is capable is sending or receiving in the duration of 1 microframe.

Only the active configuration is examined. The calculation is based on the wMaxPacketSize field in the endpoint descriptor as described in section 9.6.6 in the USB 2.0 specifications.

If acting on an isochronous or interrupt endpoint, this function will multiply the value found in bits 0:10 by the number of transactions per microframe (determined by bits 11:12). Otherwise, this function just returns the numeric value found in bits 0:10.

This function is useful for setting up isochronous transfers, for example you might pass the return value from this function to libusb_set_iso_packet_lengths() in order to set the length field of every isochronous packet in a transfer.

Convenience function for finding a device with a particular idVendor/idProduct combination.

This function is intended for those scenarios where you are using libusb to knock up a quick test application - it allows you to avoid calling libusb_get_device_list() and worrying about traversing/freeing the list.

This function has limitations and is hence not intended for use in real applications: if multiple devices have the same IDs it will only give you the first one, etc.

Parameters

ctx

the context to operate on, or NULL for the default context

vendor_id

the idVendor value to search for

product_id

the idProduct value to search for

Returns

a handle for the first found device, or NULL on error or if the device could not be found.

Determine the bConfigurationValue of the currently active configuration.

You could formulate your own control request to obtain this information, but this function has the advantage that it may be able to retrieve the information from operating system caches (no I/O involved).

If the OS does not cache this information, then this function will block while a control transfer is submitted to retrieve the information.

This function will return a value of 0 in the config output parameter if the device is in unconfigured state.

Parameters

dev

a device handle

config

output location for the bConfigurationValue of the active configuration (only valid for return code 0)

The operating system may or may not have already set an active configuration on the device. It is up to your application to ensure the correct configuration is selected before you attempt to claim interfaces and perform other operations.

If you call this function on a device already configured with the selected configuration, then this function will act as a lightweight device reset: it will issue a SET_CONFIGURATION request using the current configuration, causing most USB-related device state to be reset (altsetting reset to zero, endpoint halts cleared, toggles reset).

You cannot change/reset configuration if your application has claimed interfaces. It is advised to set the desired configuration before claiming interfaces.

Alternatively you can call libusb_release_interface() first. Note if you do things this way you must ensure that auto_detach_kernel_driver for dev is 0, otherwise the kernel driver will be re-attached when you release the interface(s).

You cannot change/reset configuration if other applications or drivers have claimed interfaces.

A configuration value of -1 will put the device in unconfigured state. The USB specifications state that a configuration value of 0 does this, however buggy devices exist which actually have a configuration 0.

You should always use this function rather than formulating your own SET_CONFIGURATION control request. This is because the underlying operating system needs to know when such changes happen.

This is a blocking function.

Parameters

dev

a device handle

configuration

the bConfigurationValue of the configuration you wish to activate, or -1 if you wish to put the device in an unconfigured state

You must claim the interface you wish to use before you can perform I/O on any of its endpoints.

It is legal to attempt to claim an already-claimed interface, in which case libusb just returns 0 without doing anything.

If auto_detach_kernel_driver is set to 1 for dev, the kernel driver will be detached if necessary, on failure the detach error is returned.

Claiming of interfaces is a purely logical operation; it does not cause any requests to be sent over the bus. Interface claiming is used to instruct the underlying operating system that your application wishes to take ownership of the interface.

This is a non-blocking function.

Parameters

dev

a device handle

interface_number

the bInterfaceNumber of the interface you wish to claim

Returns

0 on success

LIBUSB_ERROR_NOT_FOUND if the requested interface does not exist

LIBUSB_ERROR_BUSY if another program or driver has claimed the interface

The system will attempt to restore the previous configuration and alternate settings after the reset has completed.

If the reset fails, the descriptors change, or the previous state cannot be restored, the device will appear to be disconnected and reconnected. This means that the device handle is no longer valid (you should close it) and rediscover the device. A return code of LIBUSB_ERROR_NOT_FOUND indicates when this is the case.

This is a blocking function which usually incurs a noticeable delay.

Parameters

dev

a handle of the device to reset

Returns

0 on success

LIBUSB_ERROR_NOT_FOUND if re-enumeration is required, or if the device has been disconnected