summaryrefslogtreecommitdiff
path: root/libusb
diff options
context:
space:
mode:
Diffstat (limited to 'libusb')
-rw-r--r--libusb/core.c132
-rw-r--r--libusb/descriptor.c4
-rw-r--r--libusb/hotplug.c6
-rw-r--r--libusb/hotplug.h2
-rw-r--r--libusb/io.c232
-rw-r--r--libusb/libusb-1.0.rc2
-rw-r--r--libusb/libusb.h79
-rw-r--r--libusb/libusbi.h18
-rw-r--r--libusb/os/darwin_usb.c8
-rw-r--r--libusb/os/darwin_usb.h2
-rw-r--r--libusb/os/linux_usbfs.c12
-rw-r--r--libusb/os/netbsd_usb.c2
-rw-r--r--libusb/os/openbsd_usb.c2
-rw-r--r--libusb/os/poll_windows.c4
-rw-r--r--libusb/os/threads_posix.c2
-rw-r--r--libusb/os/threads_posix.h2
-rw-r--r--libusb/os/threads_windows.c2
-rw-r--r--libusb/os/threads_windows.h2
-rw-r--r--libusb/os/wince_usb.c2
-rw-r--r--libusb/os/wince_usb.h4
-rw-r--r--libusb/os/windows_common.h2
-rw-r--r--libusb/os/windows_usb.c16
-rw-r--r--libusb/os/windows_usb.h2
-rw-r--r--libusb/strerror.c4
-rw-r--r--libusb/sync.c12
-rw-r--r--libusb/version_nano.h2
26 files changed, 280 insertions, 277 deletions
diff --git a/libusb/core.c b/libusb/core.c
index f48517b..3ff22c1 100644
--- a/libusb/core.c
+++ b/libusb/core.c
@@ -1,6 +1,6 @@
/* -*- Mode: C; indent-tabs-mode:t ; c-basic-offset:8 -*- */
/*
- * Core functions for libusbx
+ * Core functions for libusb
* Copyright © 2012-2013 Nathan Hjelm <hjelmn@cs.unm.edu>
* Copyright © 2007-2008 Daniel Drake <dsd@gentoo.org>
* Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
@@ -63,7 +63,7 @@ const struct usbi_os_backend * const usbi_backend = &wince_backend;
struct libusb_context *usbi_default_context = NULL;
static const struct libusb_version libusb_version_internal =
{ LIBUSB_MAJOR, LIBUSB_MINOR, LIBUSB_MICRO, LIBUSB_NANO,
- LIBUSB_RC, "http://libusbx.org" };
+ LIBUSB_RC, "http://libusb.info" };
static int default_context_refcnt = 0;
static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
static struct timeval timestamp_origin = { 0, 0 };
@@ -72,18 +72,18 @@ usbi_mutex_static_t active_contexts_lock = USBI_MUTEX_INITIALIZER;
struct list_head active_contexts_list;
/**
- * \mainpage libusbx-1.0 API Reference
+ * \mainpage libusb-1.0 API Reference
*
* \section intro Introduction
*
- * libusbx is an open source library that allows you to communicate with USB
+ * libusb is an open source library that allows you to communicate with USB
* devices from userspace. For more info, see the
- * <a href="http://libusbx.org">libusbx homepage</a>.
+ * <a href="http://libusb.info">libusb homepage</a>.
*
* This documentation is aimed at application developers wishing to
* communicate with USB peripherals from their own software. After reviewing
* this documentation, feedback and questions can be sent to the
- * <a href="http://mailing-list.libusbx.org">libusbx-devel mailing list</a>.
+ * <a href="http://mailing-list.libusb.info">libusb-devel mailing list</a>.
*
* This documentation assumes knowledge of how to operate USB devices from
* a software standpoint (descriptors, configurations, interfaces, endpoints,
@@ -107,25 +107,25 @@ struct list_head active_contexts_list;
* \section gettingstarted Getting Started
*
* To begin reading the API documentation, start with the Modules page which
- * links to the different categories of libusbx's functionality.
+ * links to the different categories of libusb's functionality.
*
* One decision you will have to make is whether to use the synchronous
* or the asynchronous data transfer interface. The \ref io documentation
* provides some insight into this topic.
*
- * Some example programs can be found in the libusbx source distribution under
- * the "examples" subdirectory. The libusbx homepage includes a list of
- * real-life project examples which use libusbx.
+ * Some example programs can be found in the libusb source distribution under
+ * the "examples" subdirectory. The libusb homepage includes a list of
+ * real-life project examples which use libusb.
*
* \section errorhandling Error handling
*
- * libusbx functions typically return 0 on success or a negative error code
+ * libusb functions typically return 0 on success or a negative error code
* on failure. These negative error codes relate to LIBUSB_ERROR constants
* which are listed on the \ref misc "miscellaneous" documentation page.
*
* \section msglog Debug message logging
*
- * libusbx uses stderr for all logging. By default, logging is set to NONE,
+ * libusb uses stderr for all logging. By default, logging is set to NONE,
* which means that no output will be produced. However, unless the library
* has been compiled with logging disabled, then any application calls to
* libusb_set_debug(), or the setting of the environmental variable
@@ -134,19 +134,19 @@ struct list_head active_contexts_list;
* direct it to the null device if its output is undesireable.
*
* The libusb_set_debug() function can be used to enable logging of certain
- * messages. Under standard configuration, libusbx doesn't really log much
+ * messages. Under standard configuration, libusb doesn't really log much
* so you are advised to use this function to enable all error/warning/
* informational messages. It will help debug problems with your software.
*
* The logged messages are unstructured. There is no one-to-one correspondence
* between messages being logged and success or failure return codes from
- * libusbx functions. There is no format to the messages, so you should not
+ * libusb functions. There is no format to the messages, so you should not
* try to capture or parse them. They are not and will not be localized.
* These messages are not intended to being passed to your application user;
- * instead, you should interpret the error codes returned from libusbx functions
+ * instead, you should interpret the error codes returned from libusb functions
* and provide appropriate notification to the user. The messages are simply
* there to aid you as a programmer, and if you're confused because you're
- * getting a strange error code from a libusbx function, enabling message
+ * getting a strange error code from a libusb function, enabling message
* logging may give you a suitable explanation.
*
* The LIBUSB_DEBUG environment variable can be used to enable message logging
@@ -155,18 +155,18 @@ struct list_head active_contexts_list;
* environment variable is set, the message logging verbosity level is fixed
* and libusb_set_debug() effectively does nothing.
*
- * libusbx can be compiled without any logging functions, useful for embedded
+ * libusb can be compiled without any logging functions, useful for embedded
* systems. In this case, libusb_set_debug() and the LIBUSB_DEBUG environment
* variable have no effects.
*
- * libusbx can also be compiled with verbose debugging messages always. When
+ * libusb can also be compiled with verbose debugging messages always. When
* the library is compiled in this way, all messages of all verbosities are
* always logged. libusb_set_debug() and the LIBUSB_DEBUG environment variable
* have no effects.
*
* \section remarks Other remarks
*
- * libusbx does have imperfections. The \ref caveats "caveats" page attempts
+ * libusb does have imperfections. The \ref caveats "caveats" page attempts
* to document these.
*/
@@ -181,7 +181,7 @@ struct list_head active_contexts_list;
* reset).
*
* The problem is that any other program could reset the device your program
- * is working with, at any time. libusbx does not offer a mechanism to inform
+ * is working with, at any time. libusb does not offer a mechanism to inform
* you when this has happened, so if someone else resets your device it will
* not be clear to your own program why the device state has changed.
*
@@ -206,7 +206,7 @@ struct list_head active_contexts_list;
*
* \section configsel Configuration selection and handling
*
- * When libusbx presents a device handle to an application, there is a chance
+ * When libusb presents a device handle to an application, there is a chance
* that the corresponding device may be in unconfigured state. For devices
* with multiple configurations, there is also a chance that the configuration
* currently selected is not the one that the application wants to use.
@@ -217,13 +217,13 @@ struct list_head active_contexts_list;
* -# If the device is already in the desired configuration, calling
* libusb_set_configuration() using the same configuration value will cause
* a lightweight device reset. This may not be desirable behaviour.
- * -# libusbx will be unable to change configuration if the device is in
+ * -# libusb will be unable to change configuration if the device is in
* another configuration and other programs or drivers have claimed
* interfaces under that configuration.
- * -# In the case where the desired configuration is already active, libusbx
+ * -# In the case where the desired configuration is already active, libusb
* may not even be able to perform a lightweight device reset. For example,
* take my USB keyboard with fingerprint reader: I'm interested in driving
- * the fingerprint reader interface through libusbx, but the kernel's
+ * the fingerprint reader interface through libusb, but the kernel's
* USB-HID driver will almost always have claimed the keyboard interface.
* Because the kernel has claimed an interface, it is not even possible to
* perform the lightweight device reset, so libusb_set_configuration() will
@@ -263,13 +263,13 @@ if (cfg != desired)
* considerations apply to Darwin or other platforms.
*
* When a transfer completes early (i.e. when less data is received/sent in
- * any one packet than the transfer buffer allows for) then libusbx is designed
+ * any one packet than the transfer buffer allows for) then libusb is designed
* to terminate the transfer immediately, not transferring or receiving any
* more data unless other transfers have been queued by the user.
*
- * On legacy platforms, libusbx is unable to do this in all situations. After
+ * On legacy platforms, libusb is unable to do this in all situations. After
* the incomplete packet occurs, "surplus" data may be transferred. For recent
- * versions of libusbx, this information is kept (the data length of the
+ * versions of libusb, this information is kept (the data length of the
* transfer is updated) and, for device-to-host transfers, any surplus data was
* added to the buffer. Still, this is not a nice solution because it loses the
* information about the end of the short packet, and the user probably wanted
@@ -278,7 +278,7 @@ if (cfg != desired)
*
* \section zlp Zero length packets
*
- * - libusbx is able to send a packet of zero length to an endpoint simply by
+ * - libusb is able to send a packet of zero length to an endpoint simply by
* submitting a transfer of zero length.
* - The \ref libusb_transfer_flags::LIBUSB_TRANSFER_ADD_ZERO_PACKET
* "LIBUSB_TRANSFER_ADD_ZERO_PACKET" flag is currently only supported on Linux.
@@ -287,24 +287,24 @@ if (cfg != desired)
/**
* \page contexts Contexts
*
- * It is possible that libusbx may be used simultaneously from two independent
+ * It is possible that libusb may be used simultaneously from two independent
* libraries linked into the same executable. For example, if your application
* has a plugin-like system which allows the user to dynamically load a range
* of modules into your program, it is feasible that two independently
- * developed modules may both use libusbx.
+ * developed modules may both use libusb.
*
- * libusbx is written to allow for these multiple user scenarios. The two
- * "instances" of libusbx will not interfere: libusb_set_debug() calls
+ * libusb is written to allow for these multiple user scenarios. The two
+ * "instances" of libusb will not interfere: libusb_set_debug() calls
* from one user will not affect the same settings for other users, other
- * users can continue using libusbx after one of them calls libusb_exit(), etc.
+ * users can continue using libusb after one of them calls libusb_exit(), etc.
*
- * This is made possible through libusbx's <em>context</em> concept. When you
+ * This is made possible through libusb's <em>context</em> concept. When you
* call libusb_init(), you are (optionally) given a context. You can then pass
- * this context pointer back into future libusbx functions.
+ * this context pointer back into future libusb functions.
*
* In order to keep things simple for more simplistic applications, it is
* legal to pass NULL to all functions requiring a context pointer (as long as
- * you're sure no other code will attempt to use libusbx from the same process).
+ * you're sure no other code will attempt to use libusb from the same process).
* When you pass NULL, the default context will be used. The default context
* is created the first time a process calls libusb_init() when no other
* context is alive. Contexts are destroyed during libusb_exit().
@@ -317,17 +317,17 @@ if (cfg != desired)
* reference count goes from 0 to 1, and is deinitialized and destroyed when
* its reference count goes from 1 to 0.
*
- * You may be wondering why only a subset of libusbx functions require a
- * context pointer in their function definition. Internally, libusbx stores
+ * You may be wondering why only a subset of libusb functions require a
+ * context pointer in their function definition. Internally, libusb stores
* context pointers in other objects (e.g. libusb_device instances) and hence
* can infer the context from those objects.
*/
/**
* @defgroup lib Library initialization/deinitialization
- * This page details how to initialize and deinitialize libusbx. Initialization
- * must be performed before using any libusbx functionality, and similarly you
- * must not call any libusbx functions after deinitialization.
+ * This page details how to initialize and deinitialize libusb. Initialization
+ * must be performed before using any libusb functionality, and similarly you
+ * must not call any libusb functions after deinitialization.
*/
/**
@@ -384,7 +384,7 @@ libusb_free_device_list(list, 1);
* device.
*
* \section devshandles Devices and device handles
- * libusbx has a concept of a USB device, represented by the
+ * libusb has a concept of a USB device, represented by the
* \ref 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.
@@ -400,8 +400,8 @@ libusb_free_device_list(list, 1);
* using the device.
*
* When you've found a device that you'd like to operate, you must ask
- * libusbx to open the device using the libusb_open() function. Assuming
- * success, libusbx then returns you a <em>device handle</em>
+ * libusb to open the device using the libusb_open() function. Assuming
+ * success, libusb then returns you a <em>device handle</em>
* (a \ref libusb_device_handle pointer). All "real" I/O operations then
* operate on the handle rather than the original device pointer.
*
@@ -409,10 +409,10 @@ libusb_free_device_list(list, 1);
*
* 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. libusbx also needs to know when it is OK to free
+ * you are done with it. libusb also needs to know when it is OK to free
* the contents of the list - the devices themselves.
*
- * To handle these issues, libusbx provides you with two separate items:
+ * To handle these issues, libusb provides you with two separate items:
* - A function to free the list itself
* - A reference counting system for the devices inside
*
@@ -608,7 +608,7 @@ int usbi_sanitize_device(struct libusb_device *dev)
return 0;
}
-/* Examine libusbx's internal list of known devices, looking for one with
+/* Examine libusb's internal list of known devices, looking for one with
* a specific session ID. Returns the matching device if it was found, and
* NULL otherwise. */
struct libusb_device *usbi_get_device_by_session_id(struct libusb_context *ctx,
@@ -763,7 +763,7 @@ uint8_t API_EXPORTED libusb_get_port_number(libusb_device *dev)
/** \ingroup dev
* Get the list of all port numbers from root for the specified device
*
- * Since version 1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102
+ * Since version 1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102
* \param dev a device
* \param port_numbers the array that should contain the port numbers
* \param port_numbers_len the maximum length of the array. As per the USB 3.0
@@ -811,7 +811,7 @@ int API_EXPORTED libusb_get_port_path(libusb_context *ctx, libusb_device *dev,
* \returns the device parent or NULL if not available
* You should issue a \ref libusb_get_device_list() before calling this
* function and make sure that you only access the parent before issuing
- * \ref libusb_free_device_list(). The reason is that libusbx currently does
+ * \ref libusb_free_device_list(). The reason is that libusb currently does
* not maintain a permanent list of device instances, and therefore can
* only guarantee that parents are fully instantiated within a
* libusb_get_device_list() - libusb_free_device_list() block.
@@ -1120,7 +1120,7 @@ int API_EXPORTED libusb_open(libusb_device *dev,
/* At this point, we want to interrupt any existing event handlers so
* that they realise the addition of the new device's poll fd. One
* example when this is desirable is if the user is running a separate
- * dedicated libusbx events handling thread, which is running with a long
+ * dedicated libusb events handling thread, which is running with a long
* or infinite timeout. We want to interrupt that iteration of the loop,
* so that it picks up the new fd, and then continues. */
usbi_fd_notification(ctx);
@@ -1131,7 +1131,7 @@ int API_EXPORTED libusb_open(libusb_device *dev,
/** \ingroup dev
* Convenience function for finding a device with a particular
* <tt>idVendor</tt>/<tt>idProduct</tt> combination. This function is intended
- * for those scenarios where you are using libusbx to knock up a quick test
+ * 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.
*
@@ -1425,7 +1425,7 @@ int API_EXPORTED libusb_set_configuration(libusb_device_handle *dev,
* 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 libusbx just returns 0 without doing anything.
+ * case libusb just returns 0 without doing anything.
*
* If auto_detach_kernel_driver is set to 1 for <tt>dev</tt>, the kernel driver
* will be detached if necessary, on failure the detach error is returned.
@@ -1617,7 +1617,7 @@ int API_EXPORTED libusb_reset_device(libusb_device_handle *dev)
/** \ingroup dev
* Determine if a kernel driver is active on an interface. If a kernel driver
- * is active, you cannot claim the interface, and libusbx will be unable to
+ * is active, you cannot claim the interface, and libusb will be unable to
* perform I/O.
*
* This functionality is not available on Windows.
@@ -1652,7 +1652,7 @@ int API_EXPORTED libusb_kernel_driver_active(libusb_device_handle *dev,
*
* This functionality is not available on Darwin or Windows.
*
- * Note that libusbx itself also talks to the device through a special kernel
+ * Note that libusb itself also talks to the device through a special kernel
* driver, if this driver is already attached to the device, this call will
* not detach it and return LIBUSB_ERROR_NOT_FOUND.
*
@@ -1716,15 +1716,15 @@ int API_EXPORTED libusb_attach_kernel_driver(libusb_device_handle *dev,
}
/** \ingroup dev
- * Enable/disable libusbx's automatic kernel driver detachment. When this is
- * enabled libusbx will automatically detach the kernel driver on an interface
+ * Enable/disable libusb's automatic kernel driver detachment. When this is
+ * enabled libusb will automatically detach the kernel driver on an interface
* when claiming the interface, and attach it when releasing the interface.
*
* Automatic kernel driver detachment is disabled on newly opened device
* handles by default.
*
* On platforms which do not have LIBUSB_CAP_SUPPORTS_DETACH_KERNEL_DRIVER
- * this function will return LIBUSB_ERROR_NOT_SUPPORTED, and libusbx will
+ * this function will return LIBUSB_ERROR_NOT_SUPPORTED, and libusb will
* continue as if this function was never called.
*
* \param dev a device handle
@@ -1754,19 +1754,19 @@ int API_EXPORTED libusb_set_auto_detach_kernel_driver(
* printed. If you choose to increase the message verbosity level, ensure
* that your application does not close the stdout/stderr file descriptors.
*
- * You are advised to use level LIBUSB_LOG_LEVEL_WARNING. libusbx is conservative
+ * You are advised to use level LIBUSB_LOG_LEVEL_WARNING. libusb is conservative
* with its message logging and most of the time, will only log messages that
* explain error conditions and other oddities. This will help you debug
* your software.
*
- * If the LIBUSB_DEBUG environment variable was set when libusbx was
+ * If the LIBUSB_DEBUG environment variable was set when libusb was
* initialized, this function does nothing: the message verbosity is fixed
* to the value in the environment variable.
*
- * If libusbx was compiled without any message logging, this function does
+ * If libusb was compiled without any message logging, this function does
* nothing: you'll never get any messages.
*
- * If libusbx was compiled with verbose debug message logging, this function
+ * If libusb was compiled with verbose debug message logging, this function
* does nothing: you'll always get messages from all levels.
*
* \param ctx the context to operate on, or NULL for the default context
@@ -1781,7 +1781,7 @@ void API_EXPORTED libusb_set_debug(libusb_context *ctx, int level)
/** \ingroup lib
* Initialize libusb. This function must be called before calling any other
- * libusbx function.
+ * libusb function.
*
* If you do not provide an output location for a context pointer, a default
* context will be created. If there was already a default context, it will
@@ -1836,7 +1836,7 @@ int API_EXPORTED libusb_init(libusb_context **context)
usbi_dbg("created default context");
}
- usbi_dbg("libusbx v%d.%d.%d.%d", libusb_version_internal.major, libusb_version_internal.minor,
+ usbi_dbg("libusb v%d.%d.%d.%d", libusb_version_internal.major, libusb_version_internal.minor,
libusb_version_internal.micro, libusb_version_internal.nano);
usbi_mutex_init(&ctx->usb_devs_lock, NULL);
@@ -2152,11 +2152,11 @@ void usbi_log_v(struct libusb_context *ctx, enum libusb_log_level level,
if (global_debug) {
header_len = snprintf(buf, sizeof(buf),
- "[%2d.%06d] [%08x] libusbx: %s [%s] ",
+ "[%2d.%06d] [%08x] libusb: %s [%s] ",
(int)now.tv_sec, (int)now.tv_usec, usbi_get_tid(), prefix, function);
} else {
header_len = snprintf(buf, sizeof(buf),
- "libusbx: %s [%s] ", prefix, function);
+ "libusb: %s [%s] ", prefix, function);
}
if (header_len < 0 || header_len >= sizeof(buf)) {
@@ -2193,7 +2193,7 @@ void usbi_log(struct libusb_context *ctx, enum libusb_log_level level,
}
/** \ingroup misc
- * Returns a constant NULL-terminated string with the ASCII name of a libusbx
+ * Returns a constant NULL-terminated string with the ASCII name of a libusb
* error or transfer status code. The caller must not free() the returned
* string.
*
diff --git a/libusb/descriptor.c b/libusb/descriptor.c
index e1c4915..93d34ce 100644
--- a/libusb/descriptor.c
+++ b/libusb/descriptor.c
@@ -1,6 +1,6 @@
/* -*- Mode: C; indent-tabs-mode:t ; c-basic-offset:8 -*- */
/*
- * USB descriptor handling functions for libusbx
+ * USB descriptor handling functions for libusb
* Copyright © 2007 Daniel Drake <dsd@gentoo.org>
* Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
*
@@ -541,7 +541,7 @@ int usbi_device_cache_descriptor(libusb_device *dev)
*
* This is a non-blocking function; the device descriptor is cached in memory.
*
- * Note since libusbx-1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102, this
+ * Note since libusb-1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102, this
* function always succeeds.
*
* \param dev the device
diff --git a/libusb/hotplug.c b/libusb/hotplug.c
index 081bc79..7c6331a 100644
--- a/libusb/hotplug.c
+++ b/libusb/hotplug.c
@@ -1,6 +1,6 @@
/* -*- Mode: C; indent-tabs-mode:t ; c-basic-offset:8 -*- */
/*
- * Hotplug functions for libusbx
+ * Hotplug functions for libusb
* Copyright © 2012-2013 Nathan Hjelm <hjelmn@mac.com>
* Copyright © 2012-2013 Peter Stuge <peter@stuge.se>
*
@@ -45,7 +45,7 @@
*
* \section intro Introduction
*
- * Version 1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102, has added support
+ * Version 1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102, has added support
* for hotplug events on <b>some</b> platforms (you should test if your platform
* supports hotplug notification by calling \ref libusb_has_capability() with
* parameter \ref LIBUSB_CAP_HAS_HOTPLUG).
@@ -80,7 +80,7 @@
* are invalid and will remain so even if the device comes back.
*
* When handling a LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED event it is considered
- * safe to call any libusbx function that takes a libusb_device. On the other hand,
+ * safe to call any libusb function that takes a libusb_device. On the other hand,
* when handling a LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT event the only safe function
* is libusb_get_device_descriptor().
*
diff --git a/libusb/hotplug.h b/libusb/hotplug.h
index 614ddbc..321a0a8 100644
--- a/libusb/hotplug.h
+++ b/libusb/hotplug.h
@@ -1,6 +1,6 @@
/* -*- Mode: C; indent-tabs-mode:t ; c-basic-offset:8 -*- */
/*
- * Hotplug support for libusbx
+ * Hotplug support for libusb
* Copyright © 2012-2013 Nathan Hjelm <hjelmn@mac.com>
* Copyright © 2012-2013 Peter Stuge <peter@stuge.se>
*
diff --git a/libusb/io.c b/libusb/io.c
index a2c3dda..a9c611d 100644
--- a/libusb/io.c
+++ b/libusb/io.c
@@ -1,6 +1,6 @@
/* -*- Mode: C; indent-tabs-mode:t ; c-basic-offset:8 -*- */
/*
- * I/O functions for libusbx
+ * I/O functions for libusb
* Copyright © 2007-2009 Daniel Drake <dsd@gentoo.org>
* Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
*
@@ -43,10 +43,10 @@
*
* \section intro Introduction
*
- * If you're using libusbx in your application, you're probably wanting to
+ * If you're using libusb in your application, you're probably wanting to
* perform I/O with devices - you want to perform USB data transfers.
*
- * libusbx offers two separate interfaces for device I/O. This page aims to
+ * libusb offers two separate interfaces for device I/O. This page aims to
* introduce the two in order to help you decide which one is more suitable
* for your application. You can also choose to use both interfaces in your
* application by considering each transfer on a case-by-case basis.
@@ -76,7 +76,7 @@
* Data will arrive when the button is pressed by the user, which is
* potentially hours later.
*
- * libusbx offers both a synchronous and an asynchronous interface to performing
+ * libusb offers both a synchronous and an asynchronous interface to performing
* USB transfers. The main difference is that the synchronous interface
* combines both steps indicated above into a single function call, whereas
* the asynchronous interface separates them.
@@ -131,9 +131,9 @@ if (r == 0 && actual_length == sizeof(data)) {
* above.
*
* Instead of providing which functions that block until the I/O has complete,
- * libusbx's asynchronous interface presents non-blocking functions which
+ * libusb's asynchronous interface presents non-blocking functions which
* begin a transfer and then return immediately. Your application passes a
- * callback function pointer to this non-blocking function, which libusbx will
+ * callback function pointer to this non-blocking function, which libusb will
* call with the results of the transaction when it has completed.
*
* Transfers which have been submitted through the non-blocking functions
@@ -144,12 +144,12 @@ if (r == 0 && actual_length == sizeof(data)) {
* to use threads.
*
* This added flexibility does come with some complications though:
- * - In the interest of being a lightweight library, libusbx does not create
+ * - In the interest of being a lightweight library, libusb does not create
* threads and can only operate when your application is calling into it. Your
- * application must call into libusbx from it's main loop when events are ready
- * to be handled, or you must use some other scheme to allow libusbx to
+ * application must call into libusb from it's main loop when events are ready
+ * to be handled, or you must use some other scheme to allow libusb to
* undertake whatever work needs to be done.
- * - libusbx also needs to be called into at certain fixed points in time in
+ * - libusb also needs to be called into at certain fixed points in time in
* order to accurately handle transfer timeouts.
* - Memory handling becomes more complex. You cannot use stack memory unless
* the function with that stack is guaranteed not to return until the transfer
@@ -159,7 +159,7 @@ if (r == 0 && actual_length == sizeof(data)) {
* results are handled. This becomes particularly obvious when you want to
* submit a second transfer based on the results of an earlier transfer.
*
- * Internally, libusbx's synchronous interface is expressed in terms of function
+ * Internally, libusb's synchronous interface is expressed in terms of function
* calls to the asynchronous interface.
*
* For details on how to use the asynchronous API, see the
@@ -176,25 +176,25 @@ if (r == 0 && actual_length == sizeof(data)) {
* constraints on packet size defined by endpoint descriptors. The host must
* not send data payloads larger than the endpoint's maximum packet size.
*
- * libusbx and the underlying OS abstract out the packet concept, allowing you
+ * libusb and the underlying OS abstract out the packet concept, allowing you
* to request transfers of any size. Internally, the request will be divided
* up into correctly-sized packets. You do not have to be concerned with
* packet sizes, but there is one exception when considering overflows.
*
* \section overflow Bulk/interrupt transfer overflows
*
- * When requesting data on a bulk endpoint, libusbx requires you to supply a
- * buffer and the maximum number of bytes of data that libusbx can put in that
+ * When requesting data on a bulk endpoint, libusb requires you to supply a
+ * buffer and the maximum number of bytes of data that libusb can put in that
* buffer. However, the size of the buffer is not communicated to the device -
* the device is just asked to send any amount of data.
*
* There is no problem if the device sends an amount of data that is less than
- * or equal to the buffer size. libusbx reports this condition to you through
+ * or equal to the buffer size. libusb reports this condition to you through
* the \ref libusb_transfer::actual_length "libusb_transfer.actual_length"
* field.
*
* Problems may occur if the device attempts to send more data than can fit in
- * the buffer. libusbx reports LIBUSB_TRANSFER_OVERFLOW for this condition but
+ * the buffer. libusb reports LIBUSB_TRANSFER_OVERFLOW for this condition but
* other behaviour is largely undefined: actual_length may or may not be
* accurate, the chunk of data that can fit in the buffer (before overflow)
* may or may not have been transferred.
@@ -212,7 +212,7 @@ if (r == 0 && actual_length == sizeof(data)) {
/**
* @defgroup asyncio Asynchronous device I/O
*
- * This page details libusbx's asynchronous (non-blocking) API for USB device
+ * This page details libusb's asynchronous (non-blocking) API for USB device
* I/O. This interface is very powerful but is also quite complex - you will
* need to read this page carefully to understand the necessary considerations
* and issues surrounding use of this interface. Simplistic applications
@@ -227,7 +227,7 @@ if (r == 0 && actual_length == sizeof(data)) {
*
* \section asyncabstraction Transfer abstraction
*
- * For the asynchronous I/O, libusbx implements the concept of a generic
+ * For the asynchronous I/O, libusb implements the concept of a generic
* transfer entity for all types of I/O (control, bulk, interrupt,
* isochronous). The generic transfer object must be treated slightly
* differently depending on which type of I/O you are performing with it.
@@ -240,7 +240,7 @@ if (r == 0 && actual_length == sizeof(data)) {
* -# <b>Allocation</b>: allocate a libusb_transfer
* -# <b>Filling</b>: populate the libusb_transfer instance with information
* about the transfer you wish to perform
- * -# <b>Submission</b>: ask libusbx to submit the transfer
+ * -# <b>Submission</b>: ask libusb to submit the transfer
* -# <b>Completion handling</b>: examine transfer results in the
* libusb_transfer structure
* -# <b>Deallocation</b>: clean up resources
@@ -287,7 +287,7 @@ if (r == 0 && actual_length == sizeof(data)) {
*
* The user-specified callback is passed a pointer to the libusb_transfer
* structure which was used to setup and submit the transfer. At completion
- * time, libusbx has populated this structure with results of the transfer:
+ * time, libusb has populated this structure with results of the transfer:
* success or failure reason, number of bytes of data transferred, etc. See
* the libusb_transfer structure documentation for more information.
*
@@ -326,7 +326,7 @@ if (r == 0 && actual_length == sizeof(data)) {
* has completed will result in undefined behaviour.
*
* When a transfer is cancelled, some of the data may have been transferred.
- * libusbx will communicate this to you in the transfer callback. Do not assume
+ * libusb will communicate this to you in the transfer callback. Do not assume
* that no data was transferred.
*
* \section bulk_overflows Overflows on device-to-host bulk/interrupt endpoints
@@ -468,7 +468,7 @@ if (r == 0 && actual_length == sizeof(data)) {
*
* In most circumstances, it is not safe to use stack memory for transfer
* buffers. This is because the function that fired off the asynchronous
- * transfer may return before libusbx has finished using the buffer, and when
+ * transfer may return before libusb has finished using the buffer, and when
* the function returns it's stack gets destroyed. This is true for both
* host-to-device and device-to-host transfers.
*
@@ -488,43 +488,43 @@ if (r == 0 && actual_length == sizeof(data)) {
* \ref libusb_transfer_status::LIBUSB_TRANSFER_ERROR "LIBUSB_TRANSFER_ERROR"
* (they would normally be regarded as COMPLETED)
* - \ref libusb_transfer_flags::LIBUSB_TRANSFER_FREE_BUFFER
- * "LIBUSB_TRANSFER_FREE_BUFFER" allows you to ask libusbx to free the transfer
+ * "LIBUSB_TRANSFER_FREE_BUFFER" allows you to ask libusb to free the transfer
* buffer when freeing the transfer.
* - \ref libusb_transfer_flags::LIBUSB_TRANSFER_FREE_TRANSFER
- * "LIBUSB_TRANSFER_FREE_TRANSFER" causes libusbx to automatically free the
+ * "LIBUSB_TRANSFER_FREE_TRANSFER" causes libusb to automatically free the
* transfer after the transfer callback returns.
*
* \section asyncevent Event handling
*
- * An asynchronous model requires that libusbx perform work at various
+ * An asynchronous model requires that libusb perform work at various
* points in time - namely processing the results of previously-submitted
* transfers and invoking the user-supplied callback function.
*
* This gives rise to the libusb_handle_events() function which your
- * application must call into when libusbx has work do to. This gives libusbx
+ * application must call into when libusb has work do to. This gives libusb
* the opportunity to reap pending transfers, invoke callbacks, etc.
*
* There are 2 different approaches to dealing with libusb_handle_events:
*
* -# Repeatedly call libusb_handle_events() in blocking mode from a dedicated
* thread.
- * -# Integrate libusbx with your application's main event loop. libusbx
+ * -# Integrate libusb with your application's main event loop. libusb
* exposes a set of file descriptors which allow you to do this.
*
* The first approach has the big advantage that it will also work on Windows
- * were libusbx' poll API for select / poll integration is not available. So
+ * were libusb' poll API for select / poll integration is not available. So
* if you want to support Windows and use the async API, you must use this
* approach, see the \ref eventthread "Using an event handling thread" section
* below for details.
*
* If you prefer a single threaded approach with a single central event loop,
- * see the \ref poll "polling and timing" section for how to integrate libusbx
+ * see the \ref poll "polling and timing" section for how to integrate libusb
* into your application's main event loop.
*
* \section eventthread Using an event handling thread
*
* Lets begin with stating the obvious: If you're going to use a separate
- * thread for libusbx event handling, your callback functions MUST be
+ * thread for libusb event handling, your callback functions MUST be
* threadsafe.
*
* Other then that doing event handling from a separate thread, is mostly
@@ -545,7 +545,7 @@ void *event_thread_func(void *ctx)
* libusb_handle_events() will not return.
*
* There are 2 different ways of dealing with this, depending on if your
- * application uses libusbx' \ref hotplug "hotplug" support or not.
+ * application uses libusb' \ref hotplug "hotplug" support or not.
*
* Applications which do not use hotplug support, should not start the event
* thread until after their first call to libusb_open(), and should stop the
@@ -582,7 +582,7 @@ void my_libusb_exit(void)
/**
* @defgroup poll Polling and timing
*
- * This page documents libusbx's functions for polling events and timing.
+ * This page documents libusb's functions for polling events and timing.
* These functions are only necessary for users of the
* \ref asyncio "asynchronous API". If you are only using the simpler
* \ref syncio "synchronous API" then you do not need to ever call these
@@ -590,28 +590,28 @@ void my_libusb_exit(void)
*
* The justification for the functionality described here has already been
* discussed in the \ref asyncevent "event handling" section of the
- * asynchronous API documentation. In summary, libusbx does not create internal
+ * asynchronous API documentation. In summary, libusb does not create internal
* threads for event processing and hence relies on your application calling
- * into libusbx at certain points in time so that pending events can be handled.
+ * into libusb at certain points in time so that pending events can be handled.
*
* Your main loop is probably already calling poll() or select() or a
* variant on a set of file descriptors for other event sources (e.g. keyboard
* button presses, mouse movements, network sockets, etc). You then add
- * libusbx's file descriptors to your poll()/select() calls, and when activity
+ * libusb's file descriptors to your poll()/select() calls, and when activity
* is detected on such descriptors you know it is time to call
* libusb_handle_events().
*
- * There is one final event handling complication. libusbx supports
+ * There is one final event handling complication. libusb supports
* asynchronous transfers which time out after a specified time period.
*
* On some platforms a timerfd is used, so the timeout handling is just another
- * fd, on other platforms this requires that libusbx is called into at or after
- * the timeout to handle it. So, in addition to considering libusbx's file
- * descriptors in your main event loop, you must also consider that libusbx
+ * fd, on other platforms this requires that libusb is called into at or after
+ * the timeout to handle it. So, in addition to considering libusb's file
+ * descriptors in your main event loop, you must also consider that libusb
* sometimes needs to be called into at fixed points in time even when there
* is no file descriptor activity, see \ref polltime details.
*
- * In order to know precisely when libusbx needs to be called into, libusbx
+ * In order to know precisely when libusb needs to be called into, libusb
* offers you a set of pollable file descriptors and information about when
* the next timeout expires.
*
@@ -620,10 +620,10 @@ void my_libusb_exit(void)
*
* \section pollsimple The simple option
*
- * If your application revolves solely around libusbx and does not need to
+ * If your application revolves solely around libusb and does not need to
* handle other event sources, you can have a program structure as follows:
\code
-// initialize libusbx
+// initialize libusb
// find and open device
// maybe fire off some initial async I/O
@@ -646,15 +646,15 @@ while (user_has_not_requested_exit)
*
* In more advanced applications, you will already have a main loop which
* is monitoring other event sources: network sockets, X11 events, mouse
- * movements, etc. Through exposing a set of file descriptors, libusbx is
+ * movements, etc. Through exposing a set of file descriptors, libusb is
* designed to cleanly integrate into such main loops.
*
* In addition to polling file descriptors for the other event sources, you
- * take a set of file descriptors from libusbx and monitor those too. When you
- * detect activity on libusbx's file descriptors, you call
+ * take a set of file descriptors from libusb and monitor those too. When you
+ * detect activity on libusb's file descriptors, you call
* libusb_handle_events_timeout() in non-blocking mode.
*
- * What's more, libusbx may also need to handle events at specific moments in
+ * What's more, libusb may also need to handle events at specific moments in
* time. No file descriptor activity is generated at these times, so your
* own application needs to be continually aware of when the next one of these
* moments occurs (through calling libusb_get_next_timeout()), and then it
@@ -662,25 +662,25 @@ while (user_has_not_requested_exit)
* these moments occur. This means that you need to adjust your
* poll()/select() timeout accordingly.
*
- * libusbx provides you with a set of file descriptors to poll and expects you
+ * libusb provides you with a set of file descriptors to poll and expects you
* to poll all of them, treating them as a single entity. The meaning of each
* file descriptor in the set is an internal implementation detail,
* platform-dependent and may vary from release to release. Don't try and
- * interpret the meaning of the file descriptors, just do as libusbx indicates,
+ * interpret the meaning of the file descriptors, just do as libusb indicates,
* polling all of them at once.
*
* In pseudo-code, you want something that looks like:
\code
-// initialise libusbx
+// initialise libusb
libusb_get_pollfds(ctx)
while (user has not requested application exit) {
libusb_get_next_timeout(ctx);
- poll(on libusbx file descriptors plus any other event sources of interest,
- using a timeout no larger than the value libusbx just suggested)
- if (poll() indicated activity on libusbx file descriptors)
+ poll(on libusb file descriptors plus any other event sources of interest,
+ using a timeout no larger than the value libusb just suggested)
+ if (poll() indicated activity on libusb file descriptors)
libusb_handle_events_timeout(ctx, &zero_tv);
- if (time has elapsed to or beyond the libusbx timeout)
+ if (time has elapsed to or beyond the libusb timeout)
libusb_handle_events_timeout(ctx, &zero_tv);
// handle events from other sources here
}
@@ -690,7 +690,7 @@ while (user has not requested application exit) {
*
* \subsection polltime Notes on time-based events
*
- * The above complication with having to track time and call into libusbx at
+ * The above complication with having to track time and call into libusb at
* specific moments is a bit of a headache. For maximum compatibility, you do
* need to write your main loop as above, but you may decide that you can
* restrict the supported platforms of your application and get away with
@@ -702,18 +702,18 @@ while (user has not requested application exit) {
* - Linux, provided that the following version requirements are satisfied:
* - Linux v2.6.27 or newer, compiled with timerfd support
* - glibc v2.9 or newer
- * - libusbx v1.0.5 or newer
+ * - libusb v1.0.5 or newer
*
* Under these configurations, libusb_get_next_timeout() will \em always return
* 0, so your main loop can be simplified to:
\code
-// initialise libusbx
+// initialise libusb
libusb_get_pollfds(ctx)
while (user has not requested application exit) {
- poll(on libusbx file descriptors plus any other event sources of interest,
+ poll(on libusb file descriptors plus any other event sources of interest,
using any timeout that you like)
- if (poll() indicated activity on libusbx file descriptors)
+ if (poll() indicated activity on libusb file descriptors)
libusb_handle_events_timeout(ctx, &zero_tv);
// handle events from other sources here
}
@@ -723,20 +723,20 @@ while (user has not requested application exit) {
*
* Do remember that if you simplify your main loop to the above, you will
* lose compatibility with some platforms (including legacy Linux platforms,
- * and <em>any future platforms supported by libusbx which may have time-based
+ * and <em>any future platforms supported by libusb which may have time-based
* event requirements</em>). The resultant problems will likely appear as
* strange bugs in your application.
*
* You can use the libusb_pollfds_handle_timeouts() function to do a runtime
* check to see if it is safe to ignore the time-based event complications.
- * If your application has taken the shortcut of ignoring libusbx's next timeout
+ * If your application has taken the shortcut of ignoring libusb's next timeout
* in your main loop, then you are advised to check the return value of
* libusb_pollfds_handle_timeouts() during application startup, and to abort
* if the platform does suffer from these timing complications.
*
* \subsection fdsetchange Changes in the file descriptor set
*
- * The set of file descriptors that libusbx uses as event sources may change
+ * The set of file descriptors that libusb uses as event sources may change
* during the life of your application. Rather than having to repeatedly
* call libusb_get_pollfds(), you can set up notification functions for when
* the file descriptor set changes using libusb_set_pollfd_notifiers().
@@ -757,10 +757,10 @@ while (user has not requested application exit) {
/** \page mtasync Multi-threaded applications and asynchronous I/O
*
- * libusbx is a thread-safe library, but extra considerations must be applied
- * to applications which interact with libusbx from multiple threads.
+ * libusb is a thread-safe library, but extra considerations must be applied
+ * to applications which interact with libusb from multiple threads.
*
- * The underlying issue that must be addressed is that all libusbx I/O
+ * The underlying issue that must be addressed is that all libusb I/O
* revolves around monitoring file descriptors through the poll()/select()
* system calls. This is directly exposed at the
* \ref asyncio "asynchronous interface" but it is important to note that the
@@ -768,13 +768,13 @@ while (user has not requested application exit) {
* asynchonrous interface, therefore the same considerations apply.
*
* The issue is that if two or more threads are concurrently calling poll()
- * or select() on libusbx's file descriptors then only one of those threads
+ * or select() on libusb's file descriptors then only one of those threads
* will be woken up when an event arrives. The others will be completely
* oblivious that anything has happened.
*
* Consider the following pseudo-code, which submits an asynchronous transfer
* then waits for its completion. This style is one way you could implement a
- * synchronous interface on top of the asynchronous interface (and libusbx
+ * synchronous interface on top of the asynchronous interface (and libusb
* does something similar, albeit more advanced due to the complications
* explained on this page).
*
@@ -797,7 +797,7 @@ void myfunc() {
libusb_submit_transfer(transfer);
while (!completed) {
- poll(libusbx file descriptors, 120*1000);
+ poll(libusb file descriptors, 120*1000);
if (poll indicates activity)
libusb_handle_events_timeout(ctx, &zero_tv);
}
@@ -811,7 +811,7 @@ void myfunc() {
* The poll() loop has a long timeout to minimize CPU usage during situations
* when nothing is happening (it could reasonably be unlimited).
*
- * If this is the only thread that is polling libusbx's file descriptors, there
+ * If this is the only thread that is polling libusb's file descriptors, there
* is no problem: there is no danger that another thread will swallow up the
* event that we are interested in. On the other hand, if there is another
* thread polling the same descriptors, there is a chance that it will receive
@@ -823,13 +823,13 @@ void myfunc() {
*
* The solution here is to ensure that no two threads are ever polling the
* file descriptors at the same time. A naive implementation of this would
- * impact the capabilities of the library, so libusbx offers the scheme
+ * impact the capabilities of the library, so libusb offers the scheme
* documented below to ensure no loss of functionality.
*
* Before we go any further, it is worth mentioning that all libusb-wrapped
* event handling procedures fully adhere to the scheme documented below.
* This includes libusb_handle_events() and its variants, and all the
- * synchronous I/O functions - libusbx hides this headache from you.
+ * synchronous I/O functions - libusb hides this headache from you.
*
* \section Using libusb_handle_events() from multiple threads
*
@@ -875,17 +875,17 @@ void myfunc() {
*
* \section eventlock The events lock
*
- * The problem is when we consider the fact that libusbx exposes file
+ * The problem is when we consider the fact that libusb exposes file
* descriptors to allow for you to integrate asynchronous USB I/O into
* existing main loops, effectively allowing you to do some work behind
- * libusbx's back. If you do take libusbx's file descriptors and pass them to
+ * libusb's back. If you do take libusb's file descriptors and pass them to
* poll()/select() yourself, you need to be aware of the associated issues.
*
* The first concept to be introduced is the events lock. The events lock
* is used to serialize threads that want to handle events, such that only
* one thread is handling events at any one time.
*
- * You must take the events lock before polling libusbx file descriptors,
+ * You must take the events lock before polling libusb file descriptors,
* using libusb_lock_events(). You must release the lock as soon as you have
* aborted your poll()/select() loop, using libusb_unlock_events().
*
@@ -896,7 +896,7 @@ void myfunc() {
\code
libusb_lock_events(ctx);
while (!completed) {
- poll(libusbx file descriptors, 120*1000);
+ poll(libusb file descriptors, 120*1000);
if (poll indicates activity)
libusb_handle_events_timeout(ctx, &zero_tv);
}
@@ -912,7 +912,7 @@ void myfunc() {
* status of its transfer until the code above has finished (30 seconds later)
* due to contention on the lock.
*
- * To solve this, libusbx offers you a mechanism to determine when another
+ * To solve this, libusb offers you a mechanism to determine when another
* thread is handling events. It also offers a mechanism to block your thread
* until the event handling thread has completed an event (and this mechanism
* does not involve polling of file descriptors).
@@ -938,7 +938,7 @@ if (libusb_try_lock_events(ctx) == 0) {
libusb_unlock_events(ctx);
goto retry;
}
- poll(libusbx file descriptors, 120*1000);
+ poll(libusb file descriptors, 120*1000);
if (poll indicates activity)
libusb_handle_events_locked(ctx, 0);
}
@@ -984,8 +984,8 @@ printf("completed!\n");
* should be apparent from the code shown above.
* -# libusb_try_lock_events() is a non-blocking function which attempts
* to acquire the events lock but returns a failure code if it is contended.
- * -# libusb_event_handling_ok() checks that libusbx is still happy for your
- * thread to be performing event handling. Sometimes, libusbx needs to
+ * -# libusb_event_handling_ok() checks that libusb is still happy for your
+ * thread to be performing event handling. Sometimes, libusb needs to
* interrupt the event handler, and this is how you can check if you have
* been interrupted. If this function returns 0, the correct behaviour is
* for you to give up the event handling lock, and then to repeat the cycle.
@@ -995,12 +995,12 @@ printf("completed!\n");
* libusb_handle_events_timeout() that you can call while holding the
* events lock. libusb_handle_events_timeout() itself implements similar
* logic to the above, so be sure not to call it when you are
- * "working behind libusbx's back", as is the case here.
+ * "working behind libusb's back", as is the case here.
* -# libusb_event_handler_active() determines if someone is currently
* holding the events lock
*
* You might be wondering why there is no function to wake up all threads
- * blocked on libusb_wait_for_event(). This is because libusbx can do this
+ * blocked on libusb_wait_for_event(). This is because libusb can do this
* internally: it will wake up all such threads when someone calls
* libusb_unlock_events() or when a transfer completes (at the point after its
* callback has returned).
@@ -1009,7 +1009,7 @@ printf("completed!\n");
*
* The above explanation should be enough to get you going, but if you're
* really thinking through the issues then you may be left with some more
- * questions regarding libusbx's internals. If you're curious, read on, and if
+ * questions regarding libusb's internals. If you're curious, read on, and if
* not, skip to the next section to avoid confusing yourself!
*
* The immediate question that may spring to mind is: what if one thread
@@ -1024,14 +1024,14 @@ printf("completed!\n");
* are all kinds of race conditions that could arise here, so it is
* important that nobody is doing event handling at this time.
*
- * libusbx handles these issues internally, so application developers do not
+ * libusb handles these issues internally, so application developers do not
* have to stop their event handlers while opening/closing devices. Here's how
* it works, focusing on the libusb_close() situation first:
*
- * -# During initialization, libusbx opens an internal pipe, and it adds the read
+ * -# During initialization, libusb opens an internal pipe, and it adds the read
* end of this pipe to the set of file descriptors to be polled.
- * -# During libusb_close(), libusbx writes some dummy data on this control pipe.
- * This immediately interrupts the event handler. libusbx also records
+ * -# During libusb_close(), libusb writes some dummy data on this control pipe.
+ * This immediately interrupts the event handler. libusb also records
* internally that it is trying to interrupt event handlers for this
* high-priority event.
* -# At this point, some of the functions described above start behaving
@@ -1046,7 +1046,7 @@ printf("completed!\n");
* giving up the events lock very quickly, giving the high-priority
* libusb_close() operation a "free ride" to acquire the events lock. All
* threads that are competing to do event handling become event waiters.
- * -# With the events lock held inside libusb_close(), libusbx can safely remove
+ * -# With the events lock held inside libusb_close(), libusb can safely remove
* a file descriptor from the poll set, in the safety of knowledge that
* nobody is polling those descriptors or trying to access the poll set.
* -# After obtaining the events lock, the close operation completes very
@@ -1063,7 +1063,7 @@ printf("completed!\n");
* call to libusb_open():
*
* -# The device is opened and a file descriptor is added to the poll set.
- * -# libusbx sends some dummy data on the control pipe, and records that it
+ * -# libusb sends some dummy data on the control pipe, and records that it
* is trying to modify the poll descriptor set.
* -# The event handler is interrupted, and the same behaviour change as for
* libusb_close() takes effect, causing all event handling threads to become
@@ -1079,7 +1079,7 @@ printf("completed!\n");
*
* The above may seem a little complicated, but hopefully I have made it clear
* why such complications are necessary. Also, do not forget that this only
- * applies to applications that take libusbx's file descriptors and integrate
+ * applies to applications that take libusb's file descriptors and integrate
* them into their own polling loops.
*
* You may decide that it is OK for your multi-threaded application to ignore
@@ -1291,7 +1291,7 @@ out:
}
/** \ingroup asyncio
- * Allocate a libusbx transfer with a specified number of isochronous packet
+ * Allocate a libusb transfer with a specified number of isochronous packet
* descriptors. The returned transfer is pre-initialized for you. When the new
* transfer is no longer needed, it should be freed with
* libusb_free_transfer().
@@ -1589,11 +1589,11 @@ int usbi_handle_transfer_cancellation(struct usbi_transfer *transfer)
/** \ingroup poll
* Attempt to acquire the event handling lock. This lock is used to ensure that
- * only one thread is monitoring libusbx event sources at any one time.
+ * only one thread is monitoring libusb event sources at any one time.
*
* You only need to use this lock if you are developing an application
- * which calls poll() or select() on libusbx's file descriptors directly.
- * If you stick to libusbx's event handling loop functions (e.g.
+ * which calls poll() or select() on libusb's file descriptors directly.
+ * If you stick to libusb's event handling loop functions (e.g.
* libusb_handle_events()) then you do not need to be concerned with this
* locking.
*
@@ -1633,11 +1633,11 @@ int API_EXPORTED libusb_try_lock_events(libusb_context *ctx)
/** \ingroup poll
* Acquire the event handling lock, blocking until successful acquisition if
* it is contended. This lock is used to ensure that only one thread is
- * monitoring libusbx event sources at any one time.
+ * monitoring libusb event sources at any one time.
*
* You only need to use this lock if you are developing an application
- * which calls poll() or select() on libusbx's file descriptors directly.
- * If you stick to libusbx's event handling loop functions (e.g.
+ * which calls poll() or select() on libusb's file descriptors directly.
+ * If you stick to libusb's event handling loop functions (e.g.
* libusb_handle_events()) then you do not need to be concerned with this
* locking.
*
@@ -1680,7 +1680,7 @@ void API_EXPORTED libusb_unlock_events(libusb_context *ctx)
/** \ingroup poll
* Determine if it is still OK for this thread to be doing event handling.
*
- * Sometimes, libusbx needs to temporarily pause all event handlers, and this
+ * Sometimes, libusb needs to temporarily pause all event handlers, and this
* is the function you should use before polling file descriptors to see if
* this is the case.
*
@@ -1754,9 +1754,9 @@ int API_EXPORTED libusb_event_handler_active(libusb_context *ctx)
* events, then call libusb_wait_for_event().
*
* You only need to use this lock if you are developing an application
- * which calls poll() or select() on libusbx's file descriptors directly,
+ * which calls poll() or select() on libusb's file descriptors directly,
* <b>and</b> may potentially be handling events from 2 threads simultaenously.
- * If you stick to libusbx's event handling loop functions (e.g.
+ * If you stick to libusb's event handling loop functions (e.g.
* libusb_handle_events()) then you do not need to be concerned with this
* locking.
*
@@ -2093,7 +2093,7 @@ static int get_next_timeout(libusb_context *ctx, struct timeval *tv,
/** \ingroup poll
* Handle any pending events.
*
- * libusbx determines "pending events" by checking if any timeouts have expired
+ * libusb determines "pending events" by checking if any timeouts have expired
* and by checking the set of file descriptors for activity.
*
* If a zero timeval is passed, this function will handle any already-pending
@@ -2242,9 +2242,9 @@ int API_EXPORTED libusb_handle_events_completed(libusb_context *ctx,
* held, see libusb_lock_events().
*
* This function is designed to be called under the situation where you have
- * taken the event lock and are calling poll()/select() directly on libusbx's
+ * taken the event lock and are calling poll()/select() directly on libusb's
* file descriptors (as opposed to using libusb_handle_events() or similar).
- * You detect events on libusbx's descriptors, so you then call this function
+ * You detect events on libusb's descriptors, so you then call this function
* with a zero timeout value (while still holding the event lock).
*
* \param ctx the context to operate on, or NULL for the default context
@@ -2271,19 +2271,19 @@ int API_EXPORTED libusb_handle_events_locked(libusb_context *ctx,
/** \ingroup poll
* Determines whether your application must apply special timing considerations
- * when monitoring libusbx's file descriptors.
+ * when monitoring libusb's file descriptors.
*
* This function is only useful for applications which retrieve and poll
- * libusbx's file descriptors in their own main loop (\ref pollmain).
+ * libusb's file descriptors in their own main loop (\ref pollmain).
*
- * Ordinarily, libusbx's event handler needs to be called into at specific
+ * Ordinarily, libusb's event handler needs to be called into at specific
* moments in time (in addition to times when there is activity on the file
* descriptor set). The usual approach is to use libusb_get_next_timeout()
* to learn about when the next timeout occurs, and to adjust your
* poll()/select() timeout accordingly so that you can make a call into the
* library at that time.
*
- * Some platforms supported by libusbx do not come with this baggage - any
+ * Some platforms supported by libusb do not come with this baggage - any
* events relevant to timing will be represented by activity on the file
* descriptor set, and libusb_get_next_timeout() will always return 0.
* This function allows you to detect whether you are running on such a
@@ -2292,10 +2292,10 @@ int API_EXPORTED libusb_handle_events_locked(libusb_context *ctx,
* Since v1.0.5.
*
* \param ctx the context to operate on, or NULL for the default context
- * \returns 0 if you must call into libusbx at times determined by
+ * \returns 0 if you must call into libusb at times determined by
* libusb_get_next_timeout(), or 1 if all timeout events are handled internally
* or through regular activity on the file descriptors.
- * \see \ref pollmain "Polling libusbx file descriptors for event handling"
+ * \see \ref pollmain "Polling libusb file descriptors for event handling"
*/
int API_EXPORTED libusb_pollfds_handle_timeouts(libusb_context *ctx)
{
@@ -2309,21 +2309,21 @@ int API_EXPORTED libusb_pollfds_handle_timeouts(libusb_context *ctx)
}
/** \ingroup poll
- * Determine the next internal timeout that libusbx needs to handle. You only
+ * Determine the next internal timeout that libusb needs to handle. You only
* need to use this function if you are calling poll() or select() or similar
- * on libusbx's file descriptors yourself - you do not need to use it if you
+ * on libusb's file descriptors yourself - you do not need to use it if you
* are calling libusb_handle_events() or a variant directly.
*
* You should call this function in your main loop in order to determine how
- * long to wait for select() or poll() to return results. libusbx needs to be
+ * long to wait for select() or poll() to return results. libusb needs to be
* called into at this timeout, so you should use it as an upper bound on
* your select() or poll() call.
*
* When the timeout has expired, call into libusb_handle_events_timeout()
- * (perhaps in non-blocking mode) so that libusbx can handle the timeout.
+ * (perhaps in non-blocking mode) so that libusb can handle the timeout.
*
* This function may return 1 (success) and an all-zero timeval. If this is
- * the case, it indicates that libusbx has a timeout that has already expired
+ * the case, it indicates that libusb has a timeout that has already expired
* so you should call libusb_handle_events_timeout() or similar immediately.
* A return code of 0 indicates that there are no pending timeouts.
*
@@ -2332,7 +2332,7 @@ int API_EXPORTED libusb_pollfds_handle_timeouts(libusb_context *ctx)
*
* \param ctx the context to operate on, or NULL for the default context
* \param tv output location for a relative time against the current
- * clock in which libusbx must be called into in order to process timeout events
+ * clock in which libusb must be called into in order to process timeout events
* \returns 0 if there are no pending timeouts, 1 if a timeout was returned,
* or LIBUSB_ERROR_OTHER on failure
*/
@@ -2399,7 +2399,7 @@ int API_EXPORTED libusb_get_next_timeout(libusb_context *ctx,
/** \ingroup poll
* Register notification functions for file descriptor additions/removals.
* These functions will be invoked for every new or removed file descriptor
- * that libusbx uses as an event source.
+ * that libusb uses as an event source.
*
* To remove notifiers, pass NULL values for the function pointers.
*
@@ -2477,7 +2477,7 @@ void usbi_remove_pollfd(struct libusb_context *ctx, int fd)
/** \ingroup poll
* Retrieve a list of file descriptors that should be polled by your main loop
- * as libusbx event sources.
+ * as libusb event sources.
*
* The returned list is NULL-terminated and should be freed with free() when
* done. The actual list contents must not be touched.
@@ -2517,7 +2517,7 @@ out:
usbi_mutex_unlock(&ctx->pollfds_lock);
return (const struct libusb_pollfd **) ret;
#else
- usbi_err(ctx, "external polling of libusbx's internal descriptors "\
+ usbi_err(ctx, "external polling of libusb's internal descriptors "\
"is not yet supported on Windows platforms");
return NULL;
#endif
diff --git a/libusb/libusb-1.0.rc b/libusb/libusb-1.0.rc
index ae49757..3dce6d5 100644
--- a/libusb/libusb-1.0.rc
+++ b/libusb/libusb-1.0.rc
@@ -41,7 +41,7 @@ BEGIN
BEGIN
BLOCK "040904b0"
BEGIN
- VALUE "CompanyName", "libusbx.org\0"
+ VALUE "CompanyName", "libusb.info\0"
VALUE "FileDescription", "C library for writing portable USB drivers in userspace\0"
VALUE "FileVersion", LIBUSB_VERSIONSTRING
VALUE "InternalName", "libusb\0"
diff --git a/libusb/libusb.h b/libusb/libusb.h
index 8267ee3..409b510 100644
--- a/libusb/libusb.h
+++ b/libusb/libusb.h
@@ -1,10 +1,10 @@
/*
- * Public libusbx header file
+ * Public libusb header file
* Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
* Copyright © 2007-2008 Daniel Drake <dsd@gentoo.org>
* Copyright © 2012 Pete Batard <pete@akeo.ie>
* Copyright © 2012 Nathan Hjelm <hjelmn@cs.unm.edu>
- * For more information, please visit: http://libusbx.org
+ * For more information, please visit: http://libusb.info
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -62,7 +62,7 @@ typedef unsigned __int32 uint32_t;
#include <limits.h>
/* 'interface' might be defined as a macro on Windows, so we need to
- * undefine it so as not to break the current libusbx API, because
+ * undefine it so as not to break the current libusb API, because
* libusb_config_descriptor has an 'interface' member
* As this can be problematic if you include windows.h after libusb.h
* in your sources, we force windows.h to be included first. */
@@ -85,14 +85,14 @@ typedef unsigned __int32 uint32_t;
/** \def LIBUSB_CALL
* \ingroup misc
- * libusbx's Windows calling convention.
+ * libusb's Windows calling convention.
*
* Under Windows, the selection of available compilers and configurations
* means that, unlike other platforms, there is not <em>one true calling
* convention</em> (calling convention: the manner in which parameters are
* passed to funcions in the generated assembly code).
*
- * Matching the Windows API itself, libusbx uses the WINAPI convention (which
+ * Matching the Windows API itself, libusb uses the WINAPI convention (which
* translates to the <tt>stdcall</tt> convention) and guarantees that the
* library is compiled in this way. The public header file also includes
* appropriate annotations so that your own software will use the right
@@ -100,7 +100,7 @@ typedef unsigned __int32 uint32_t;
* your codebase.
*
* The one consideration that you must apply in your software is to mark
- * all functions which you use as libusbx callbacks with this LIBUSB_CALL
+ * all functions which you use as libusb callbacks with this LIBUSB_CALL
* annotation, so that they too get compiled for the correct calling
* convention.
*
@@ -108,7 +108,7 @@ typedef unsigned __int32 uint32_t;
* means that you can apply it to your code without worrying about
* cross-platform compatibility.
*/
-/* LIBUSB_CALL must be defined on both definition and declaration of libusbx
+/* LIBUSB_CALL must be defined on both definition and declaration of libusb
* functions. You'd think that declaration would be enough, but cygwin will
* complain about conflicting types unless both are marked this way.
* The placement of this macro is important too; it must appear after the
@@ -121,30 +121,33 @@ typedef unsigned __int32 uint32_t;
#define LIBUSB_CALL
#endif
-/** \def LIBUSBX_API_VERSION
+/** \def LIBUSB_API_VERSION
* \ingroup misc
- * libusbx's API version.
+ * libusb's API version.
*
- * Since version 1.0.13, to help with feature detection, libusbx defines
- * a LIBUSBX_API_VERSION macro that gets increased every time there is a
+ * Since version 1.0.13, to help with feature detection, libusb defines
+ * a LIBUSB_API_VERSION macro that gets increased every time there is a
* significant change to the API, such as the introduction of a new call,
* the definition of a new macro/enum member, or any other element that
- * libusbx applications may want to detect at compilation time.
+ * libusb applications may want to detect at compilation time.
*
* The macro is typically used in an application as follows:
* \code
- * #if defined(LIBUSBX_API_VERSION) && (LIBUSBX_API_VERSION >= 0x01001234)
- * // Use one of the newer features from the libusbx API
+ * #if defined(LIBUSB_API_VERSION) && (LIBUSB_API_VERSION >= 0x01001234)
+ * // Use one of the newer features from the libusb API
* #endif
* \endcode
*
- * Another feature of LIBUSBX_API_VERSION is that it can be used to detect
- * whether you are compiling against the libusb or the libusbx library.
+ * Another feature of LIBUSB_API_VERSION is that it can be used to detect
+ * whether you are compiling against the libusb or the libusb library.
*
- * Internally, LIBUSBX_API_VERSION is defined as follows:
- * (libusbx major << 24) | (libusbx minor << 16) | (16 bit incremental)
+ * Internally, LIBUSB_API_VERSION is defined as follows:
+ * (libusb major << 24) | (libusb minor << 16) | (16 bit incremental)
*/
-#define LIBUSBX_API_VERSION 0x01000102
+#define LIBUSB_API_VERSION 0x01000102
+
+/* The following is kept for compatibility, but will be deprecated in the future */
+#define LIBUSBX_API_VERSION LIBUSB_API_VERSION
#ifdef __cplusplus
extern "C" {
@@ -562,7 +565,7 @@ struct libusb_endpoint_descriptor {
/** For audio devices only: the address if the synch endpoint */
uint8_t bSynchAddress;
- /** Extra descriptors. If libusbx encounters unknown endpoint descriptors,
+ /** Extra descriptors. If libusb encounters unknown endpoint descriptors,
* it will store them here, should you wish to parse them. */
const unsigned char *extra;
@@ -612,7 +615,7 @@ struct libusb_interface_descriptor {
* by the bNumEndpoints field. */
const struct libusb_endpoint_descriptor *endpoint;
- /** Extra descriptors. If libusbx encounters unknown interface descriptors,
+ /** Extra descriptors. If libusb encounters unknown interface descriptors,
* it will store them here, should you wish to parse them. */
const unsigned char *extra;
@@ -670,7 +673,7 @@ struct libusb_config_descriptor {
* this array is determined by the bNumInterfaces field. */
const struct libusb_interface *interface;
- /** Extra descriptors. If libusbx encounters unknown configuration
+ /** Extra descriptors. If libusb encounters unknown configuration
* descriptors, it will store them here, should you wish to parse them. */
const unsigned char *extra;
@@ -889,7 +892,7 @@ struct libusb_control_setup {
#define LIBUSB_CONTROL_SETUP_SIZE (sizeof(struct libusb_control_setup))
-/* libusbx */
+/* libusb */
struct libusb_context;
struct libusb_device;
@@ -897,7 +900,7 @@ struct libusb_device_handle;
struct libusb_hotplug_callback;
/** \ingroup lib
- * Structure providing the version of the libusbx runtime
+ * Structure providing the version of the libusb runtime
*/
struct libusb_version {
/** Library major version. */
@@ -920,16 +923,16 @@ struct libusb_version {
};
/** \ingroup lib
- * Structure representing a libusbx session. The concept of individual libusbx
+ * Structure representing a libusb session. The concept of individual libusb
* sessions allows for your program to use two libraries (or dynamically
* load two modules) which both independently use libusb. This will prevent
- * interference between the individual libusbx users - for example
+ * interference between the individual libusb users - for example
* libusb_set_debug() will not affect the other user of the library, and
* libusb_exit() will not destroy resources that the other user is still
* using.
*
* Sessions are created by libusb_init() and destroyed through libusb_exit().
- * If your application is guaranteed to only ever include a single libusbx
+ * If your application is guaranteed to only ever include a single libusb
* user (i.e. you), you do not have to worry about contexts: pass NULL in
* every function call where a context is required. The default context
* will be used.
@@ -1042,7 +1045,7 @@ enum libusb_bos_type {
};
/** \ingroup misc
- * Error codes. Most libusbx functions return 0 on success or one of these
+ * Error codes. Most libusb functions return 0 on success or one of these
* codes on failure.
* You can call libusb_error_name() to retrieve a string representation of an
* error code or libusb_strerror() to get an end-user suitable description of
@@ -1188,7 +1191,7 @@ struct libusb_transfer;
* Asynchronous transfer callback function type. When submitting asynchronous
* transfers, you pass a pointer to a callback function of this type via the
* \ref libusb_transfer::callback "callback" member of the libusb_transfer
- * structure. libusbx will call this function later, when the transfer has
+ * structure. libusb will call this function later, when the transfer has
* completed or failed. See \ref asyncio for more information.
* \param transfer The libusb_transfer struct the callback function is being
* notified about.
@@ -1271,7 +1274,7 @@ enum libusb_capability {
LIBUSB_CAP_HAS_HOTPLUG = 0x0001,
/** The library can access HID devices without requiring user intervention.
* Note that before being able to actually access an HID device, you may
- * still have to call additional libusbx functions such as
+ * still have to call additional libusb functions such as
* \ref libusb_detach_kernel_driver(). */
LIBUSB_CAP_HAS_HID_ACCESS = 0x0100,
/** The library supports detaching of the default USB driver, using
@@ -1829,7 +1832,7 @@ void LIBUSB_CALL libusb_set_pollfd_notifiers(libusb_context *ctx,
* per libusb_context and it is safe to call libusb_hotplug_deregister_callback()
* on an already deregisted callback.
*
- * Since version 1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102
+ * Since version 1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102
*
* For more information, see \ref hotplug.
*/
@@ -1837,7 +1840,7 @@ typedef int libusb_hotplug_callback_handle;
/** \ingroup hotplug
*
- * Since version 1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102
+ * Since version 1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102
*
* Flags for hotplug events */
typedef enum {
@@ -1847,7 +1850,7 @@ typedef enum {
/** \ingroup hotplug
*
- * Since version 1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102
+ * Since version 1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102
*
* Hotplug events */
typedef enum {
@@ -1871,13 +1874,13 @@ typedef enum {
* This callback may be called by an internal event thread and as such it is
* recommended the callback do minimal processing before returning.
*
- * libusbx will call this function later, when a matching event had happened on
+ * libusb will call this function later, when a matching event had happened on
* a matching device. See \ref hotplug for more information.
*
* It is safe to call either libusb_hotplug_register_callback() or
* libusb_hotplug_deregister_callback() from within a callback function.
*
- * Since version 1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102
+ * Since version 1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102
*
* \param ctx context of this notification
* \param device libusb_device this event occurred on
@@ -1901,7 +1904,7 @@ typedef int (LIBUSB_CALL *libusb_hotplug_callback_fn)(libusb_context *ctx,
*
* If the \ref LIBUSB_HOTPLUG_ENUMERATE is passed the callback will be
* called with a \ref LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED for all devices
- * already plugged into the machine. Note that libusbx modifies its internal
+ * already plugged into the machine. Note that libusb modifies its internal
* device list from a separate thread, while calling hotplug callbacks from
* libusb_handle_events(), so it is possible for a device to already be present
* on, or removed from, its internal device list, while the hotplug callbacks
@@ -1911,7 +1914,7 @@ typedef int (LIBUSB_CALL *libusb_hotplug_callback_fn)(libusb_context *ctx,
* from libusb_handle_events(); and/or your callback may be called for the
* removal of a device for which an arrived call was never made.
*
- * Since version 1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102
+ * Since version 1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102
*
* \param[in] ctx context to register this callback with
* \param[in] events bitwise or of events that will trigger this callback. See \ref
@@ -1940,7 +1943,7 @@ int LIBUSB_CALL libusb_hotplug_register_callback(libusb_context *ctx,
* Deregister a callback from a libusb_context. This function is safe to call from within
* a hotplug callback.
*
- * Since version 1.0.16, \ref LIBUSBX_API_VERSION >= 0x01000102
+ * Since version 1.0.16, \ref LIBUSB_API_VERSION >= 0x01000102
*
* \param[in] ctx context this callback is registered with
* \param[in] handle the handle of the callback to deregister
diff --git a/libusb/libusbi.h b/libusb/libusbi.h
index 5cf5425..7db9c59 100644
--- a/libusb/libusbi.h
+++ b/libusb/libusbi.h
@@ -1,5 +1,5 @@
/*
- * Internal header for libusbx
+ * Internal header for libusb
* Copyright © 2007-2009 Daniel Drake <dsd@gentoo.org>
* Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
*
@@ -39,11 +39,11 @@
#include "libusb.h"
#include "version.h"
-/* Inside the libusbx code, mark all public functions as follows:
+/* Inside the libusb code, mark all public functions as follows:
* return_type API_EXPORTED function_name(params) { ... }
* But if the function returns a pointer, mark it as follows:
* DEFAULT_VISIBILITY return_type * LIBUSB_CALL function_name(params) { ... }
- * In the libusbx public header, mark all declarations as:
+ * In the libusb public header, mark all declarations as:
* return_type LIBUSB_CALL function_name(params);
*/
#define API_EXPORTED LIBUSB_CALL DEFAULT_VISIBILITY
@@ -512,7 +512,7 @@ struct usbi_os_backend {
* to determine specific capabilities of the system, allocate required
* data structures for later, etc.
*
- * This function is called when a libusbx user initializes the library
+ * This function is called when a libusb user initializes the library
* prior to use.
*
* Return 0 on success, or a LIBUSB_ERROR code on failure.
@@ -542,7 +542,7 @@ struct usbi_os_backend {
* but that is an unlikely case.
*
* After computing a session ID for a device, call
- * usbi_get_device_by_session_id(). This function checks if libusbx already
+ * usbi_get_device_by_session_id(). This function checks if libusb already
* knows about the device, and if so, it provides you with a reference
* to a libusb_device structure for it.
*
@@ -603,7 +603,7 @@ struct usbi_os_backend {
*
* Your backend should allocate any internal resources required for I/O
* and other operations so that those operations can happen (hopefully)
- * without hiccup. This is also a good place to inform libusbx that it
+ * without hiccup. This is also a good place to inform libusb that it
* should monitor certain file descriptors related to this device -
* see the usbi_add_pollfd() function.
*
@@ -627,7 +627,7 @@ struct usbi_os_backend {
/* Close a device such that the handle cannot be used again. Your backend
* should destroy any resources that were allocated in the open path.
* This may also be a good place to call usbi_remove_pollfd() to inform
- * libusbx of any file descriptors associated with this device that should
+ * libusb of any file descriptors associated with this device that should
* no longer be monitored.
*
* This function is called when the user closes a device handle.
@@ -728,7 +728,7 @@ struct usbi_os_backend {
*
* If you cannot retrieve this from cache, either do not implement this
* function, or return LIBUSB_ERROR_NOT_SUPPORTED. This will cause
- * libusbx to retrieve the information through a standard control transfer.
+ * libusb to retrieve the information through a standard control transfer.
*
* This function must be non-blocking.
* Return:
@@ -927,7 +927,7 @@ struct usbi_os_backend {
* all private data from the transfer as if you were just about to report
* completion or cancellation.
*
- * This function might seem a bit out of place. It is used when libusbx
+ * This function might seem a bit out of place. It is used when libusb
* detects a disconnected device - it calls this function for all pending
* transfers before reporting completion (with the disconnect code) to
* the user. Maybe we can improve upon this internal interface in future.
diff --git a/libusb/os/darwin_usb.c b/libusb/os/darwin_usb.c
index 35385d5..d1092ec 100644
--- a/libusb/os/darwin_usb.c
+++ b/libusb/os/darwin_usb.c
@@ -1,6 +1,6 @@
/* -*- Mode: C; indent-tabs-mode:nil -*- */
/*
- * darwin backend for libusbx 1.0
+ * darwin backend for libusb 1.0
* Copyright © 2008-2013 Nathan Hjelm <hjelmn@users.sourceforge.net>
*
* This library is free software; you can redistribute it and/or
@@ -1431,7 +1431,7 @@ static int submit_bulk_transfer(struct usbi_transfer *itransfer) {
IOReturn ret;
uint8_t transferType;
- /* None of the values below are used in libusbx for bulk transfers */
+ /* None of the values below are used in libusb for bulk transfers */
uint8_t direction, number, interval, pipeRef, iface;
uint16_t maxPacketSize;
@@ -1515,7 +1515,7 @@ static int submit_iso_transfer(struct usbi_transfer *itransfer) {
return LIBUSB_ERROR_NO_MEM;
}
- /* copy the frame list from the libusbx descriptor (the structures differ only is member order) */
+ /* copy the frame list from the libusb descriptor (the structures differ only is member order) */
for (i = 0 ; i < transfer->num_iso_packets ; i++)
tpriv->isoc_framelist[i].frReqCount = transfer->iso_packet_desc[i].length;
@@ -1596,7 +1596,7 @@ static int submit_control_transfer(struct usbi_transfer *itransfer) {
tpriv->req.wValue = OSSwapLittleToHostInt16 (setup->wValue);
tpriv->req.wIndex = OSSwapLittleToHostInt16 (setup->wIndex);
tpriv->req.wLength = OSSwapLittleToHostInt16 (setup->wLength);
- /* data is stored after the libusbx control block */
+ /* data is stored after the libusb control block */
tpriv->req.pData = transfer->buffer + LIBUSB_CONTROL_SETUP_SIZE;
tpriv->req.completionTimeout = transfer->timeout;
tpriv->req.noDataTimeout = transfer->timeout;
diff --git a/libusb/os/darwin_usb.h b/libusb/os/darwin_usb.h
index 53b8542..3fa0187 100644
--- a/libusb/os/darwin_usb.h
+++ b/libusb/os/darwin_usb.h
@@ -1,5 +1,5 @@
/*
- * darwin backend for libusbx 1.0
+ * darwin backend for libusb 1.0
* Copyright © 2008-2013 Nathan Hjelm <hjelmn@users.sourceforge.net>
*
* This library is free software; you can redistribute it and/or
diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
index a95d099..50c9161 100644
--- a/libusb/os/linux_usbfs.c
+++ b/libusb/os/linux_usbfs.c
@@ -1,6 +1,6 @@
/* -*- Mode: C; c-basic-offset:8 ; indent-tabs-mode:t -*- */
/*
- * Linux usbfs backend for libusbx
+ * Linux usbfs backend for libusb
* Copyright © 2007-2009 Daniel Drake <dsd@gentoo.org>
* Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
* Copyright © 2013 Nathan Hjelm <hjelmn@mac.com>
@@ -197,10 +197,10 @@ static int _get_usbfs_fd(struct libusb_device *dev, mode_t mode, int silent)
return fd; /* Success */
if (!silent) {
- usbi_err(ctx, "libusbx couldn't open USB device %s: %s",
+ usbi_err(ctx, "libusb couldn't open USB device %s: %s",
path, strerror(errno));
if (errno == EACCES && mode == O_RDWR)
- usbi_err(ctx, "libusbx requires write access to USB "
+ usbi_err(ctx, "libusb requires write access to USB "
"device nodes.");
}
@@ -1823,7 +1823,7 @@ static int submit_bulk_transfer(struct usbi_transfer *itransfer,
* complications:
* - discarding is asynchronous - discarded urbs will be reaped
* later. the user must not have freed the transfer when the
- * discarded URBs are reaped, otherwise libusbx will be using
+ * discarded URBs are reaped, otherwise libusb will be using
* freed memory.
* - the earlier URBs may have completed successfully and we do
* not want to throw away any data.
@@ -1985,7 +1985,7 @@ static int submit_iso_transfer(struct usbi_transfer *itransfer)
* complications:
* - discarding is asynchronous - discarded urbs will be reaped
* later. the user must not have freed the transfer when the
- * discarded URBs are reaped, otherwise libusbx will be using
+ * discarded URBs are reaped, otherwise libusb will be using
* freed memory.
* - the earlier URBs may have completed successfully and we do
* not want to throw away any data.
@@ -2160,7 +2160,7 @@ static int handle_bulk_completion(struct usbi_transfer *itransfer,
*
* When this happens, our objectives are not to lose any "surplus" data,
* and also to stick it at the end of the previously-received data
- * (closing any holes), so that libusbx reports the total amount of
+ * (closing any holes), so that libusb reports the total amount of
* transferred data and presents it in a contiguous chunk.
*/
if (urb->actual_length > 0) {
diff --git a/libusb/os/netbsd_usb.c b/libusb/os/netbsd_usb.c
index 1da9e1e..d43eea3 100644
--- a/libusb/os/netbsd_usb.c
+++ b/libusb/os/netbsd_usb.c
@@ -639,7 +639,7 @@ _sync_control_transfer(struct usbi_transfer *itransfer)
req.ucr_request.bmRequestType = setup->bmRequestType;
req.ucr_request.bRequest = setup->bRequest;
- /* Don't use USETW, libusbx already deals with the endianness */
+ /* Don't use USETW, libusb already deals with the endianness */
(*(uint16_t *)req.ucr_request.wValue) = setup->wValue;
(*(uint16_t *)req.ucr_request.wIndex) = setup->wIndex;
(*(uint16_t *)req.ucr_request.wLength) = setup->wLength;
diff --git a/libusb/os/openbsd_usb.c b/libusb/os/openbsd_usb.c
index 01934ef..ef0b27b 100644
--- a/libusb/os/openbsd_usb.c
+++ b/libusb/os/openbsd_usb.c
@@ -700,7 +700,7 @@ _sync_control_transfer(struct usbi_transfer *itransfer)
req.ucr_addr = transfer->dev_handle->dev->device_address;
req.ucr_request.bmRequestType = setup->bmRequestType;
req.ucr_request.bRequest = setup->bRequest;
- /* Don't use USETW, libusbx already deals with the endianness */
+ /* Don't use USETW, libusb already deals with the endianness */
(*(uint16_t *)req.ucr_request.wValue) = setup->wValue;
(*(uint16_t *)req.ucr_request.wIndex) = setup->wIndex;
(*(uint16_t *)req.ucr_request.wLength) = setup->wLength;
diff --git a/libusb/os/poll_windows.c b/libusb/os/poll_windows.c
index abe8761..2a75c5e 100644
--- a/libusb/os/poll_windows.c
+++ b/libusb/os/poll_windows.c
@@ -22,7 +22,7 @@
*/
/*
- * poll() and pipe() Windows compatibility layer for libusbx 1.0
+ * poll() and pipe() Windows compatibility layer for libusb 1.0
*
* The way this layer works is by using OVERLAPPED with async I/O transfers, as
* OVERLAPPED have an associated event which is flagged for I/O completion.
@@ -252,7 +252,7 @@ void exit_polling(void)
/*
* Create a fake pipe.
- * As libusbx only uses pipes for signaling, all we need from a pipe is an
+ * As libusb only uses pipes for signaling, all we need from a pipe is an
* event. To that extent, we create a single wfd and overlapped as a means
* to access that event.
*/
diff --git a/libusb/os/threads_posix.c b/libusb/os/threads_posix.c
index edf7063..95c1027 100644
--- a/libusb/os/threads_posix.c
+++ b/libusb/os/threads_posix.c
@@ -1,5 +1,5 @@
/*
- * libusbx synchronization using POSIX Threads
+ * libusb synchronization using POSIX Threads
*
* Copyright © 2011 Vitali Lovich <vlovich@aliph.com>
* Copyright © 2011 Peter Stuge <peter@stuge.se>
diff --git a/libusb/os/threads_posix.h b/libusb/os/threads_posix.h
index 0b6a71a..d7a5d21 100644
--- a/libusb/os/threads_posix.h
+++ b/libusb/os/threads_posix.h
@@ -1,5 +1,5 @@
/*
- * libusbx synchronization using POSIX Threads
+ * libusb synchronization using POSIX Threads
*
* Copyright © 2010 Peter Stuge <peter@stuge.se>
*
diff --git a/libusb/os/threads_windows.c b/libusb/os/threads_windows.c
index cad27e9..ac12738 100644
--- a/libusb/os/threads_windows.c
+++ b/libusb/os/threads_windows.c
@@ -1,5 +1,5 @@
/*
- * libusbx synchronization on Microsoft Windows
+ * libusb synchronization on Microsoft Windows
*
* Copyright © 2010 Michael Plante <michael.plante@gmail.com>
*
diff --git a/libusb/os/threads_windows.h b/libusb/os/threads_windows.h
index df8a0ee..2b82925 100644
--- a/libusb/os/threads_windows.h
+++ b/libusb/os/threads_windows.h
@@ -1,5 +1,5 @@
/*
- * libusbx synchronization on Microsoft Windows
+ * libusb synchronization on Microsoft Windows
*
* Copyright © 2010 Michael Plante <michael.plante@gmail.com>
*
diff --git a/libusb/os/wince_usb.c b/libusb/os/wince_usb.c
index c7ab7f6..c48d27d 100644
--- a/libusb/os/wince_usb.c
+++ b/libusb/os/wince_usb.c
@@ -1,5 +1,5 @@
/*
- * Windows CE backend for libusbx 1.0
+ * Windows CE backend for libusb 1.0
* Copyright © 2011-2013 RealVNC Ltd.
* Large portions taken from Windows backend, which is
* Copyright © 2009-2010 Pete Batard <pbatard@gmail.com>
diff --git a/libusb/os/wince_usb.h b/libusb/os/wince_usb.h
index 3db9693..bc61b5c 100644
--- a/libusb/os/wince_usb.h
+++ b/libusb/os/wince_usb.h
@@ -1,5 +1,5 @@
/*
- * Windows CE backend for libusbx 1.0
+ * Windows CE backend for libusb 1.0
* Copyright © 2011-2013 RealVNC Ltd.
* Portions taken from Windows backend, which is
* Copyright © 2009-2010 Pete Batard <pbatard@gmail.com>
@@ -36,7 +36,7 @@
// This backend dynamically loads ceusbkwrapper.dll and doesn't include
// ceusbkwrapper.h directly to simplify the build process. The kernel
// side wrapper driver is built using the platform image build tools,
-// which makes it difficult to reference directly from the libusbx build
+// which makes it difficult to reference directly from the libusb build
// system.
struct UKW_DEVICE_PRIV;
typedef struct UKW_DEVICE_PRIV *UKW_DEVICE;
diff --git a/libusb/os/windows_common.h b/libusb/os/windows_common.h
index 1da72bd..fe95d79 100644
--- a/libusb/os/windows_common.h
+++ b/libusb/os/windows_common.h
@@ -1,5 +1,5 @@
/*
- * Windows backend common header for libusbx 1.0
+ * Windows backend common header for libusb 1.0
*
* This file brings together header code common between
* the desktop Windows and Windows CE backends.
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index 5abadc1..f0dd810 100644
--- a/libusb/os/windows_usb.c
+++ b/libusb/os/windows_usb.c
@@ -1,5 +1,5 @@
/*
- * windows backend for libusbx 1.0
+ * windows backend for libusb 1.0
* Copyright © 2009-2012 Pete Batard <pete@akeo.ie>
* With contributions from Michael Plante, Orin Eman et al.
* Parts of this code adapted from libusb-win32-v1 by Stephan Meyer
@@ -805,10 +805,10 @@ static void auto_release(struct usbi_transfer *itransfer)
}
/*
- * init: libusbx backend init function
+ * init: libusb backend init function
*
* This function enumerates the HCDs (Host Controller Drivers) and populates our private HCD list
- * In our implementation, we equate Windows' "HCD" to libusbx's "bus". Note that bus is zero indexed.
+ * In our implementation, we equate Windows' "HCD" to libusb's "bus". Note that bus is zero indexed.
* HCDs are not expected to change after init (might not hold true for hot pluggable USB PCI card?)
*/
static int windows_init(struct libusb_context *ctx)
@@ -1085,7 +1085,7 @@ static int cache_config_descriptors(struct libusb_device *dev, HANDLE hub_handle
}
/*
- * Populate a libusbx device structure
+ * Populate a libusb device structure
*/
static int init_device(struct libusb_device* dev, struct libusb_device* parent_dev,
uint8_t port_number, char* device_id, DWORD devinst)
@@ -1339,7 +1339,7 @@ static int set_hid_interface(struct libusb_context* ctx, struct libusb_device* d
}
/*
- * get_device_list: libusbx backend device enumeration function
+ * get_device_list: libusb backend device enumeration function
*/
static int windows_get_device_list(struct libusb_context *ctx, struct discovered_devs **_discdevs)
{
@@ -1489,7 +1489,7 @@ static int windows_get_device_list(struct libusb_context *ctx, struct discovered
if (!pSetupDiGetDeviceRegistryPropertyA(dev_info, &dev_info_data, SPDRP_DRIVER,
&reg_type, (BYTE*)strbuf, size, &size)) {
usbi_info(ctx, "The following device has no driver: '%s'", dev_id_path);
- usbi_info(ctx, "libusbx will not be able to access it.");
+ usbi_info(ctx, "libusb will not be able to access it.");
}
// ...and to add the additional device interface GUIDs
key = pSetupDiOpenDevRegKey(dev_info, &dev_info_data, DICS_FLAG_GLOBAL, 0, DIREG_DEV, KEY_READ);
@@ -1696,7 +1696,7 @@ static int windows_get_device_list(struct libusb_context *ctx, struct discovered
}
/*
- * exit: libusbx backend deinitialization function
+ * exit: libusb backend deinitialization function
*/
static void windows_exit(void)
{
@@ -4317,7 +4317,7 @@ static int composite_submit_control_transfer(int sub_api, struct usbi_transfer *
}
}
- usbi_err(ctx, "no libusbx supported interfaces to complete request");
+ usbi_err(ctx, "no libusb supported interfaces to complete request");
return LIBUSB_ERROR_NOT_FOUND;
}
diff --git a/libusb/os/windows_usb.h b/libusb/os/windows_usb.h
index 14ee422..069f3fc 100644
--- a/libusb/os/windows_usb.h
+++ b/libusb/os/windows_usb.h
@@ -1,5 +1,5 @@
/*
- * Windows backend for libusbx 1.0
+ * Windows backend for libusb 1.0
* Copyright © 2009-2012 Pete Batard <pete@akeo.ie>
* With contributions from Michael Plante, Orin Eman et al.
* Parts of this code adapted from libusb-win32-v1 by Stephan Meyer
diff --git a/libusb/strerror.c b/libusb/strerror.c
index 0212df8..3af1cab 100644
--- a/libusb/strerror.c
+++ b/libusb/strerror.c
@@ -35,7 +35,7 @@ static size_t usbi_locale = 0;
* How to add a new \ref libusb_strerror() translation:
* <ol>
* <li> Download the latest \c strerror.c from:<br>
- * https://raw.github.com/libusbx/libusbx/master/libusb/sterror.c </li>
+ * https://raw.github.com/libusb/libusb/master/libusb/sterror.c </li>
* <li> Open the file in an UTF-8 capable editor </li>
* <li> Add the 2 letter <a href="http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes">ISO 639-1</a>
* code for your locale at the end of \c usbi_locale_supported[]<br>
@@ -53,7 +53,7 @@ static size_t usbi_locale = 0;
* }
* };\endcode </li>
* <li> Translate each of the English messages from the section you copied into your language </li>
- * <li> Save the file (in UTF-8 format) and send it to \c libusbx-devel\@lists.sourceforge.net </li>
+ * <li> Save the file (in UTF-8 format) and send it to \c libusb-devel\@lists.sourceforge.net </li>
* </ol>
*/
diff --git a/libusb/sync.c b/libusb/sync.c
index 42e486d..d87032d 100644
--- a/libusb/sync.c
+++ b/libusb/sync.c
@@ -1,5 +1,5 @@
/*
- * Synchronous I/O functions for libusbx
+ * Synchronous I/O functions for libusb
* Copyright © 2007-2008 Daniel Drake <dsd@gentoo.org>
*
* This library is free software; you can redistribute it and/or
@@ -28,7 +28,7 @@
/**
* @defgroup syncio Synchronous device I/O
*
- * This page documents libusbx's synchronous (blocking) API for USB device I/O.
+ * This page documents libusb's synchronous (blocking) API for USB device I/O.
* This interface is easy to use but has some limitations. More advanced users
* may wish to consider using the \ref asyncio "asynchronous I/O API" instead.
*/
@@ -222,9 +222,9 @@ static int do_sync_bulk_transfer(struct libusb_device_handle *dev_handle,
* Not all of the data may have been written.
*
* Also check <tt>transferred</tt> when dealing with a timeout error code.
- * libusbx may have to split your transfer into a number of chunks to satisfy
+ * libusb may have to split your transfer into a number of chunks to satisfy
* underlying O/S requirements, meaning that the timeout may expire after
- * the first few chunks have completed. libusbx is careful not to lose any data
+ * the first few chunks have completed. libusb is careful not to lose any data
* that may have been transferred; do not assume that timeout conditions
* indicate a complete lack of I/O.
*
@@ -270,9 +270,9 @@ int API_EXPORTED libusb_bulk_transfer(struct libusb_device_handle *dev_handle,
* writes. Not all of the data may have been written.
*
* Also check <tt>transferred</tt> when dealing with a timeout error code.
- * libusbx may have to split your transfer into a number of chunks to satisfy
+ * libusb may have to split your transfer into a number of chunks to satisfy
* underlying O/S requirements, meaning that the timeout may expire after
- * the first few chunks have completed. libusbx is careful not to lose any data
+ * the first few chunks have completed. libusb is careful not to lose any data
* that may have been transferred; do not assume that timeout conditions
* indicate a complete lack of I/O.
*
diff --git a/libusb/version_nano.h b/libusb/version_nano.h
index 69887e6..0ef80dc 100644
--- a/libusb/version_nano.h
+++ b/libusb/version_nano.h
@@ -1 +1 @@
-#define LIBUSB_NANO 10861
+#define LIBUSB_NANO 10862
View Lorry Controller Status