Misc: Rebrand to libusbx

* Mentions of 'libusb' in doxygen are changed to 'libusbx'
* Also update copyright notices and remove unneeded EOF LFs

27 files changed, 280 insertions, 316 deletions

diff --git a/PORTING b/PORTING
index 7070784..9185c37 100644
--- a/PORTING
+++ b/PORTING
@@ -1,15 +1,15 @@
-PORTING LIBUSB TO OTHER PLATFORMS
+PORTING LIBUSBX TO OTHER PLATFORMS
 
 Introduction
 ============
 
-This document is aimed at developers wishing to port libusb to unsupported
-platforms. I believe the libusb API is OS-independent, so by supporting
+This document is aimed at developers wishing to port libusbx to unsupported
+platforms. I believe the libusbx API is OS-independent, so by supporting
 multiple operating systems we pave the way for cross-platform USB device
 drivers.
 
 Implementation-wise, the basic idea is that you provide an interface to
-libusb's internal "backend" API, which performs the appropriate operations on
+libusbx's internal "backend" API, which performs the appropriate operations on
 your target platform.
 
 In terms of USB I/O, your backend provides functionality to submit
@@ -27,16 +27,16 @@ e.g. setting configuration, obtaining descriptors, etc.
 File descriptors for I/O polling
 ================================
 
-For libusb to work, your event handling function obviously needs to be called
+For libusbx to work, your event handling function obviously needs to be called
 at various points in time. Your backend must provide a set of file descriptors
-which libusb and its users can pass to poll() or select() to determine when
+which libusbx and its users can pass to poll() or select() to determine when
 it is time to call the event handling function.
 
 On Linux, this is easy: the usbfs kernel interface exposes a file descriptor
 which can be passed to poll(). If something similar is not true for your
 platform, you can emulate this using an internal library thread to reap I/O as
 necessary, and a pipe() with the main library to raise events. The file
-descriptor of the pipe can then be provided to libusb as an event source.
+descriptor of the pipe can then be provided to libusbx as an event source.
 
 
 Interface semantics and documentation
@@ -46,7 +46,7 @@ Documentation of the backend interface can be found in libusbi.h inside the
 usbi_os_backend structure definition.
 
 Your implementations of these functions will need to call various internal
-libusb functions, prefixed with "usbi_". Documentation for these functions
+libusbx functions, prefixed with "usbi_". Documentation for these functions
 can be found in the .c files where they are implemented.
 
 You probably want to skim over *all* the documentation before starting your
@@ -72,18 +72,18 @@ right usbi_backend for your platform.
 
 4. Produce and test your implementation.
 
-5. Send your implementation to libusb-devel mailing list.
+5. Send your implementation to libusbx-devel mailing list.
 
 
 Implementation difficulties? Questions?
 =======================================
 
-If you encounter difficulties porting libusb to your platform, please raise
-these issues on the libusb-devel mailing list. Where possible and sensible, I
-am interested in solving problems preventing libusb from operating on other
+If you encounter difficulties porting libusbx to your platform, please raise
+these issues on the libusbx-devel mailing list. Where possible and sensible, I
+am interested in solving problems preventing libusbx from operating on other
 platforms.
 
-The libusb-devel mailing list is also a good place to ask questions and
+The libusbx-devel mailing list is also a good place to ask questions and
 make suggestions about the internal API. Hopefully we can produce some
 better documentation based on your questions and other input.
 
@@ -92,4 +92,3 @@ some infrastructure additions/modifications to better support your platform,
 you are encouraged to make such changes (in cleanly distinct patch
 submissions). Even if you do not make such changes yourself, please do raise
 the issues on the mailing list at the very minimum.
-
diff --git a/README b/README
index c5dabd7..97e79fd 100644
--- a/README
+++ b/README
@@ -1,23 +1,24 @@
-libusb
-======
+libusbx
+=======
 
-libusb is a library for USB device access from Linux, Mac OS X and
-Windows userspace.
+libusbx is a library for USB device access from Linux, Mac OS X,
+OpenBSD and Windows userspace.
 It is written in C and licensed under the LGPL-2.1 (see COPYING).
 
-libusb is abstracted internally in such a way that it can hopefully
-be ported to other operating systems. See the PORTING file for some
-information, if you fancy a challenge :)
+libusbx is abstracted internally in such a way that it can hopefully
+be ported to other operating systems. Please see the PORTING file
+for more information.
 
-libusb homepage:
-http://libusb.org/
+libusbx homepage:
+http://libusbx.org/
 
 Developers will wish to consult the API documentation:
-http://libusb.sourceforge.net/api-1.0/
+http://libusbx.sourceforge.net/api-1.0/
 
 Use the mailing list for questions, comments, etc:
-https://sourceforge.net/mailarchive/forum.php?forum_name=libusb-devel
+https://lists.sourceforge.net/lists/listinfo/libusbx-devel
 
-- Daniel Drake <dsd@gentoo.org>
-- Peter Stuge <peter@stuge.se>
+- Pete Batard <pete@akeo.ie>
+- Hans de Goede <hdegoede@redhat.com>
+- Xiaofan Chen <xiaofanc@gmail.com>
 (use the mailing list rather than mailing developers directly)
diff --git a/doc/doxygen.cfg.in b/doc/doxygen.cfg.in
index 128e1de..795335c 100644
--- a/doc/doxygen.cfg.in
+++ b/doc/doxygen.cfg.in
@@ -25,7 +25,7 @@ DOXYFILE_ENCODING      = UTF-8
 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded 
 # by quotes) that should identify the project.
 
-PROJECT_NAME           = libusb
+PROJECT_NAME           = libusbx
 
 # The PROJECT_NUMBER tag can be used to enter a project or revision number. 
 # This could be handy for archiving the generated documentation or 
diff --git a/examples/dpfp.c b/examples/dpfp.c
index 1b3c3a4..7652407 100644
--- a/examples/dpfp.c
+++ b/examples/dpfp.c
@@ -1,6 +1,6 @@
 /*
- * libusb example program to manipulate U.are.U 4000B fingerprint scanner.
- * Copyright (C) 2007 Daniel Drake <dsd@gentoo.org>
+ * libusbx example program to manipulate U.are.U 4000B fingerprint scanner.
+ * Copyright © 2007 Daniel Drake <dsd@gentoo.org>
  *
  * Basic image capture program only, does not consider the powerup quirks or
  * the fact that image encryption may be enabled. Not expected to work
diff --git a/examples/dpfp_threaded.c b/examples/dpfp_threaded.c
index c3d314d..a46d885 100644
--- a/examples/dpfp_threaded.c
+++ b/examples/dpfp_threaded.c
@@ -1,6 +1,6 @@
 /*
- * libusb example program to manipulate U.are.U 4000B fingerprint scanner.
- * Copyright (C) 2007 Daniel Drake <dsd@gentoo.org>
+ * libusbx example program to manipulate U.are.U 4000B fingerprint scanner.
+ * Copyright © 2007 Daniel Drake <dsd@gentoo.org>
  *
  * Basic image capture program only, does not consider the powerup quirks or
  * the fact that image encryption may be enabled. Not expected to work
diff --git a/examples/listdevs.c b/examples/listdevs.c
index 6ab8917..df30224 100644
--- a/examples/listdevs.c
+++ b/examples/listdevs.c
@@ -1,6 +1,6 @@
 /*
- * libusb example program to list devices on the bus
- * Copyright (C) 2007 Daniel Drake <dsd@gentoo.org>
+ * libusbx example program to list devices on the bus
+ * Copyright © 2007 Daniel Drake <dsd@gentoo.org>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
diff --git a/examples/xusb.c b/examples/xusb.c
index 970458d..b1d338f 100644
--- a/examples/xusb.c
+++ b/examples/xusb.c
@@ -1,8 +1,7 @@
 /*
  * xusb: Generic USB test program
- * Copyright (c) 2009-2011 Pete Batard <pbatard@gmail.com>
- * Based on lsusb, copyright (c) 2007 Daniel Drake <dsd@gentoo.org>
- * With contributions to Mass Storage test by Alan Stern.
+ * Copyright © 2009-2012 Pete Batard <pete@akeo.ie>
+ * Contributions to Mass Storage by Alan Stern.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -49,7 +48,7 @@
 #endif
 
 
-// Future versions of libusb will use usb_interface instead of interface
+// Future versions of libusbx will use usb_interface instead of interface
 // in libusb_config_descriptor => catter for that
 #define usb_interface interface
 
@@ -862,7 +861,7 @@ int main(int argc, char** argv)
 
 #ifdef HAS_GETVERSION
 	version = libusb_getversion(); */
-	printf("Using libusb v%d.%d.%d.%d\n\n", version->major, version->minor, version->micro, version->nano);
+	printf("Using libusbx v%d.%d.%d.%d\n\n", version->major, version->minor, version->micro, version->nano);
 #endif
 	r = libusb_init(NULL);
 	if (r < 0)
diff --git a/libusb/core.c b/libusb/core.c
index 142c6d4..f19d663 100644
--- a/libusb/core.c
+++ b/libusb/core.c
@@ -1,7 +1,7 @@
 /*
- * Core functions for libusb
- * Copyright (C) 2007-2008 Daniel Drake <dsd@gentoo.org>
- * Copyright (c) 2001 Johannes Erdfelt <johannes@erdfelt.com>
+ * Core functions for libusbx
+ * Copyright © 2007-2008 Daniel Drake <dsd@gentoo.org>
+ * Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -46,24 +46,24 @@ static int default_context_refcnt = 0;
 static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
 
 /**
- * \mainpage libusb-1.0 API Reference
+ * \mainpage libusbx-1.0 API Reference
  *
  * \section intro Introduction
  *
- * libusb is an open source library that allows you to communicate with USB
+ * libusbx is an open source library that allows you to communicate with USB
  * devices from userspace. For more info, see the
- * <a href="http://libusb.sourceforge.net">libusb homepage</a>.
+ * <a href="http://libusbx.sourceforge.net">libusbx 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://sourceforge.net/mail/?group_id=1674">libusb-devel mailing
+ * <a href="https://lists.sourceforge.net/lists/listinfo/libusbx-devel">libusbx-devel mailing
  * list</a>.
  *
  * This documentation assumes knowledge of how to operate USB devices from
  * a software standpoint (descriptors, configurations, interfaces, endpoints,
  * control/bulk/interrupt/isochronous transfers, etc). Full information
- * can be found in the <a href="http://www.usb.org/developers/docs/">USB 2.0
+ * can be found in the <a href="http://www.usb.org/developers/docs/">USB 3.0
  * Specification</a> which is available for free download. You can probably
  * find less verbose introductions by searching the web.
  *
@@ -81,43 +81,43 @@ static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
  * \section gettingstarted Getting Started
  *
  * To begin reading the API documentation, start with the Modules page which
- * links to the different categories of libusb's functionality.
+ * links to the different categories of libusbx'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 libusb source distribution under
- * the "examples" subdirectory. The libusb homepage includes a list of
- * real-life project examples which use libusb.
+ * 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.
  *
  * \section errorhandling Error handling
  *
- * libusb functions typically return 0 on success or a negative error code
+ * libusbx 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
  *
- * libusb does not log any messages by default. Your application is therefore
+ * libusbx does not log any messages by default. Your application is therefore
  * free to close stdout/stderr and those descriptors may be reused without
  * worry.
  *
  * The libusb_set_debug() function can be used to enable stdout/stderr logging
- * of certain messages. Under standard configuration, libusb doesn't really
+ * of certain messages. Under standard configuration, libusbx doesn't really
  * log much at all, so you are advised to use this function to enable all
  * error/warning/informational messages. It will help you 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
- * libusb functions. There is no format to the messages, so you should not
+ * libusbx 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 suitable for being passed to your application user;
- * instead, you should interpret the error codes returned from libusb functions
+ * instead, you should interpret the error codes returned from libusbx 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 libusb function, enabling message
+ * getting a strange error code from a libusbx function, enabling message
  * logging may give you a suitable explanation.
  *
  * The LIBUSB_DEBUG environment variable can be used to enable message logging
@@ -126,18 +126,18 @@ static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
  * environment variable is set, the message logging verbosity level is fixed
  * and libusb_set_debug() effectively does nothing.
  *
- * libusb can be compiled without any logging functions, useful for embedded
+ * libusbx 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.
  *
- * libusb can also be compiled with verbose debugging messages. When the
+ * libusbx can also be compiled with verbose debugging messages. 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
  *
- * libusb does have imperfections. The \ref caveats "caveats" page attempts
+ * libusbx does have imperfections. The \ref caveats "caveats" page attempts
  * to document these.
  */
 
@@ -152,7 +152,7 @@ static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
  * reset).
  *
  * The problem is that any other program could reset the device your program
- * is working with, at any time. libusb does not offer a mechanism to inform
+ * is working with, at any time. libusbx 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.
  *
@@ -177,12 +177,12 @@ static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
  *
  * \section nohotplug No hotplugging
  *
- * libusb-1.0 lacks functionality for providing notifications of when devices
+ * libusbx-1.0 lacks functionality for providing notifications of when devices
  * are added or removed. This functionality is planned to be implemented
- * for libusb-1.1.
+ * in a later version of libusbx.
  *
  * That said, there is basic disconnection handling for open device handles:
- *  - If there are ongoing transfers, libusb's handle_events loop will detect
+ *  - If there are ongoing transfers, libusbx's handle_events loop will detect
  *    disconnections and complete ongoing transfers with the
  *    LIBUSB_TRANSFER_NO_DEVICE status code.
  *  - Many functions such as libusb_set_configuration() return the special
@@ -190,7 +190,7 @@ static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
  *
  * \section configsel Configuration selection and handling
  *
- * When libusb presents a device handle to an application, there is a chance
+ * When libusbx 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.
@@ -201,13 +201,13 @@ static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
  * -# 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.
- * -# libusb will be unable to change configuration if the device is in
+ * -# libusbx 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, libusb
+ * -# In the case where the desired configuration is already active, libusbx
  *    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 libusb, but the kernel's
+ *    the fingerprint reader interface through libusbx, 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
@@ -247,50 +247,23 @@ 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 libusb is designed
+ * any one packet than the transfer buffer allows for) then libusbx 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, libusb is unable to do this in all situations. After
- * the incomplete packet occurs, "surplus" data may be transferred. Prior to
- * libusb v1.0.2, this information was lost (and for device-to-host transfers,
- * the corresponding data was discarded). As of libusb v1.0.3, 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 that surplus data to arrive in the next
- * logical transfer.
- *
- * A previous workaround was to only ever submit transfers of size 16kb or
- * less.
- *
- * As of libusb v1.0.4 and Linux v2.6.32, this is fixed. A technical
- * explanation of this issue follows.
- *
- * When you ask libusb to submit a bulk transfer larger than 16kb in size,
- * libusb breaks it up into a number of smaller subtransfers. This is because
- * the usbfs kernel interface only accepts transfers of up to 16kb in size.
- * The subtransfers are submitted all at once so that the kernel can queue
- * them at the hardware level, therefore maximizing bus throughput.
- *
- * On legacy platforms, this caused problems when transfers completed early.
- * Upon this event, the kernel would terminate all further packets in that
- * subtransfer (but not any following ones). libusb would note this event and
- * immediately cancel any following subtransfers that had been queued,
- * but often libusb was not fast enough, and the following subtransfers had
- * started before libusb got around to cancelling them.
- *
- * Thanks to an API extension to usbfs, this is fixed with recent kernel and
- * libusb releases. The solution was to allow libusb to communicate to the
- * kernel where boundaries occur between logical libusb-level transfers. When
- * a short transfer (or other error) occurs, the kernel will cancel all the
- * subtransfers until the boundary without allowing those transfers to start.
+ * On legacy platforms, libusbx 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
+ * 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
+ * that surplus data to arrive in the next logical transfer.
+ *
  *
  * \section zlp Zero length packets
  *
- * - libusb is able to send a packet of zero length to an endpoint simply by
- * submitting a transfer of zero length. On Linux, this did not work with
- * libusb versions prior to 1.0.3 and kernel versions prior to 2.6.31.
+ * - libusbx 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.
  */
@@ -298,24 +271,24 @@ if (cfg != desired)
 /**
  * \page contexts Contexts
  *
- * It is possible that libusb may be used simultaneously from two independent
+ * It is possible that libusbx 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 libusb.
+ * developed modules may both use libusbx.
  *
- * libusb is written to allow for these multiple user scenarios. The two
- * "instances" of libusb will not interfere: libusb_set_debug() calls
+ * libusbx is written to allow for these multiple user scenarios. The two
+ * "instances" of libusbx will not interfere: libusb_set_debug() calls
  * from one user will not affect the same settings for other users, other
- * users can continue using libusb after one of them calls libusb_exit(), etc.
+ * users can continue using libusbx after one of them calls libusb_exit(), etc.
  *
- * This is made possible through libusb's <em>context</em> concept. When you
+ * This is made possible through libusbx'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 libusb functions.
+ * this context pointer back into future libusbx 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 libusb from the same process).
+ * you're sure no other code will attempt to use libusbx 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().
@@ -328,17 +301,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 libusb functions require a
- * context pointer in their function definition. Internally, libusb stores
+ * You may be wondering why only a subset of libusbx functions require a
+ * context pointer in their function definition. Internally, libusbx 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 libusb. Initialization
- * must be performed before using any libusb functionality, and similarly you
- * must not call any libusb functions after 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.
  */
 
 /**
@@ -395,7 +368,7 @@ libusb_free_device_list(list, 1);
  * device.
  *
  * \section devshandles Devices and device handles
- * libusb has a concept of a USB device, represented by the
+ * libusbx 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.
@@ -411,8 +384,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
- * libusb to open the device using the libusb_open() function. Assuming
- * success, libusb then returns you a <em>device handle</em>
+ * libusbx to open the device using the libusb_open() function. Assuming
+ * success, libusbx 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.
  *
@@ -420,10 +393,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. libusb also needs to know when it is OK to free
+ * you are done with it. libusbx also needs to know when it is OK to free
  * the contents of the list - the devices themselves.
  *
- * To handle these issues, libusb provides you with two separate items:
+ * To handle these issues, libusbx provides you with two separate items:
  * - A function to free the list itself
  * - A reference counting system for the devices inside
  *
@@ -567,7 +540,7 @@ int usbi_sanitize_device(struct libusb_device *dev)
 	return 0;
 }
 
-/* Examine libusb's internal list of known devices, looking for one with
+/* Examine libusbx'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,
@@ -969,7 +942,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 libusb events handling thread, which is running with a long
+	 * dedicated libusbx 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);
@@ -980,7 +953,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 libusb to knock up a quick test
+ * for those scenarios where you are using libusbx to knock up a quick test
  * application - it allows you to avoid calling libusb_get_device_list() and
  * worrying about traversing/freeing the list.
  *
@@ -1266,7 +1239,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 libusb just returns 0 without doing anything.
+ * case libusbx just returns 0 without doing anything.
  *
  * Claiming of interfaces is a purely logical operation; it does not cause
  * any requests to be sent over the bus. Interface claiming is used to
@@ -1436,7 +1409,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 libusb will be unable to
+ * is active, you cannot claim the interface, and libusbx will be unable to
  * perform I/O.
  *
  * This functionality is not available on Windows.
@@ -1530,18 +1503,18 @@ int API_EXPORTED libusb_attach_kernel_driver(libusb_device_handle *dev,
  * choose to increase the message verbosity level, ensure that your
  * application does not close the stdout/stderr file descriptors.
  *
- * You are advised to set level 3. libusb is conservative with its message
+ * You are advised to set level 3. libusbx 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 libusb was
+ * If the LIBUSB_DEBUG environment variable was set when libusbx was
  * initialized, this function does nothing: the message verbosity is fixed
  * to the value in the environment variable.
  *
- * If libusb was compiled without any message logging, this function does
+ * If libusbx was compiled without any message logging, this function does
  * nothing: you'll never get any messages.
  *
- * If libusb was compiled with verbose debug message logging, this function
+ * If libusbx 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
@@ -1556,7 +1529,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
- * libusb function.
+ * libusbx 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
diff --git a/libusb/descriptor.c b/libusb/descriptor.c
index e358e9e..590d1dc 100644
--- a/libusb/descriptor.c
+++ b/libusb/descriptor.c
@@ -1,7 +1,7 @@
 /*
- * USB descriptor handling functions for libusb
- * Copyright (C) 2007 Daniel Drake <dsd@gentoo.org>
- * Copyright (c) 2001 Johannes Erdfelt <johannes@erdfelt.com>
+ * USB descriptor handling functions for libusbx
+ * Copyright © 2007 Daniel Drake <dsd@gentoo.org>
+ * Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -727,4 +727,3 @@ int API_EXPORTED libusb_get_string_descriptor_ascii(libusb_device_handle *dev,
 	data[di] = 0;
 	return di;
 }
-
diff --git a/libusb/io.c b/libusb/io.c
index c9df0cf..bb5ecf9 100644
--- a/libusb/io.c
+++ b/libusb/io.c
@@ -1,7 +1,7 @@
 /*
- * I/O functions for libusb
- * Copyright (C) 2007-2009 Daniel Drake <dsd@gentoo.org>
- * Copyright (c) 2001 Johannes Erdfelt <johannes@erdfelt.com>
+ * I/O functions for libusbx
+ * Copyright © 2007-2009 Daniel Drake <dsd@gentoo.org>
+ * Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -41,10 +41,10 @@
  *
  * \section intro Introduction
  *
- * If you're using libusb in your application, you're probably wanting to
+ * If you're using libusbx in your application, you're probably wanting to
  * perform I/O with devices - you want to perform USB data transfers.
  *
- * libusb offers two separate interfaces for device I/O. This page aims to
+ * libusbx 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.
@@ -74,7 +74,7 @@
  * Data will arrive when the button is pressed by the user, which is
  * potentially hours later.
  *
- * libusb offers both a synchronous and an asynchronous interface to performing
+ * libusbx 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,7 +131,7 @@ if (r == 0 && actual_length == sizeof(data)) {
  * Instead of providing which functions that block until the I/O has complete,
  * 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 libusb will
+ * callback function pointer to this non-blocking function, which libusbx will
  * call with the results of the transaction when it has completed.
  *
  * Transfers which have been submitted through the non-blocking functions
@@ -142,12 +142,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, libusb does not create
+ * - In the interest of being a lightweight library, libusbx does not create
  * threads and can only operate when your application is calling into it. Your
- * 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
+ * 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
  * undertake whatever work needs to be done.
- * - libusb also needs to be called into at certain fixed points in time in
+ * - libusbx 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
@@ -174,25 +174,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.
  *
- * libusb and the underlying OS abstract out the packet concept, allowing you
+ * libusbx 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, libusb requires you to supply a
- * buffer and the maximum number of bytes of data that libusb can put in that
+ * 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
  * 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. libusb reports this condition to you through
+ * or equal to the buffer size. libusbx 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. libusb reports LIBUSB_TRANSFER_OVERFLOW for this condition but
+ * the buffer. libusbx 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.
@@ -225,7 +225,7 @@ if (r == 0 && actual_length == sizeof(data)) {
  *
  * \section asyncabstraction Transfer abstraction
  *
- * For the asynchronous I/O, libusb implements the concept of a generic
+ * For the asynchronous I/O, libusbx 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.
@@ -238,7 +238,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 libusb to submit the transfer
+ * -# <b>Submission</b>: ask libusbx to submit the transfer
  * -# <b>Completion handling</b>: examine transfer results in the
  *    libusb_transfer structure
  * -# <b>Deallocation</b>: clean up resources
@@ -285,7 +285,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, libusb has populated this structure with results of the transfer:
+ * time, libusbx 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.
  *
@@ -324,7 +324,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.
- * libusb will communicate this to you in the transfer callback. Do not assume
+ * libusbx 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
@@ -466,7 +466,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 libusb has finished using the buffer, and when
+ * transfer may return before libusbx 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.
  *
@@ -486,27 +486,27 @@ 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 libusb to free the transfer
+ *   "LIBUSB_TRANSFER_FREE_BUFFER" allows you to ask libusbx to free the transfer
  *   buffer when freeing the transfer.
  * - \ref libusb_transfer_flags::LIBUSB_TRANSFER_FREE_TRANSFER
- *   "LIBUSB_TRANSFER_FREE_TRANSFER" causes libusb to automatically free the
+ *   "LIBUSB_TRANSFER_FREE_TRANSFER" causes libusbx to automatically free the
  *   transfer after the transfer callback returns.
  *
  * \section asyncevent Event handling
  *
- * In accordance of the aim of being a lightweight library, libusb does not
- * create threads internally. This means that libusb code does not execute
- * at any time other than when your application is calling a libusb function.
- * However, an asynchronous model requires that libusb perform work at various
+ * In accordance of the aim of being a lightweight library, libusbx does not
+ * create threads internally. This means that libusbx code does not execute
+ * at any time other than when your application is calling a libusbx function.
+ * However, an asynchronous model requires that libusbx 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 libusb has work do to. This gives libusb
+ * application must call into when libusbx has work do to. This gives libusbx
  * the opportunity to reap pending transfers, invoke callbacks, etc.
  *
  * The first issue to discuss here is how your application can figure out
- * when libusb has work to do. In fact, there are two naive options which
+ * when libusbx has work to do. In fact, there are two naive options which
  * do not actually require your application to know this:
  * -# Periodically call libusb_handle_events() in non-blocking mode at fixed
  *    short intervals from your main loop
@@ -519,8 +519,8 @@ if (r == 0 && actual_length == sizeof(data)) {
  * available to you if the "proper" approach can not be applied to your
  * application (read on...).
  *
- * The recommended option is to integrate libusb with your application main
- * event loop. libusb exposes a set of file descriptors which allow you to do
+ * The recommended option is to integrate libusbx with your application main
+ * event loop. libusbx exposes a set of file descriptors which allow you to do
  * this. 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
@@ -528,11 +528,11 @@ if (r == 0 && actual_length == sizeof(data)) {
  * is detected on such descriptors you know it is time to call
  * libusb_handle_events().
  *
- * There is one final event handling complication. libusb supports
+ * There is one final event handling complication. libusbx supports
  * asynchronous transfers which time out after a specified time period, and
- * this requires that libusb is called into at or after the timeout so that
+ * this requires that libusbx is called into at or after the timeout so that
  * the timeout can be handled. So, in addition to considering libusb's file
- * descriptors in your main event loop, you must also consider that libusb
+ * descriptors in your main event loop, you must also consider that libusbx
  * sometimes needs to be called into at fixed points in time even when there
  * is no file descriptor activity.
  *
@@ -551,10 +551,10 @@ if (r == 0 && actual_length == sizeof(data)) {
  *
  * 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, libusb does not create internal
+ * asynchronous API documentation. In summary, libusbx does not create internal
  * threads for event processing and hence relies on your application calling
- * into libusb at certain points in time so that pending events can be handled.
- * In order to know precisely when libusb needs to be called into, libusb
+ * into libusbx at certain points in time so that pending events can be handled.
+ * In order to know precisely when libusbx needs to be called into, libusbx
  * offers you a set of pollable file descriptors and information about when
  * the next timeout expires.
  *
@@ -563,10 +563,10 @@ if (r == 0 && actual_length == sizeof(data)) {
  *
  * \section pollsimple The simple option
  *
- * If your application revolves solely around libusb and does not need to
+ * If your application revolves solely around libusbx and does not need to
  * handle other event sources, you can have a program structure as follows:
 \code
-// initialize libusb
+// initialize libusbx
 // find and open device
 // maybe fire off some initial async I/O
 
@@ -588,15 +588,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, libusb is
+ * movements, etc. Through exposing a set of file descriptors, libusbx 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 libusb and monitor those too. When you
+ * take a set of file descriptors from libusbx 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, libusb may also need to handle events at specific moments in
+ * What's more, libusbx 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
@@ -604,25 +604,25 @@ while (user_has_not_requested_exit)
  * these moments occur. This means that you need to adjust your
  * poll()/select() timeout accordingly.
  *
- * libusb provides you with a set of file descriptors to poll and expects you
+ * libusbx 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 libusb indicates,
+ * interpret the meaning of the file descriptors, just do as libusbx indicates,
  * polling all of them at once.
  *
  * In pseudo-code, you want something that looks like:
 \code
-// initialise libusb
+// initialise libusbx
 
 libusb_get_pollfds(ctx)
 while (user has not requested application exit) {
 	libusb_get_next_timeout(ctx);
-	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)
+	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)
 		libusb_handle_events_timeout(ctx, &zero_tv);
-	if (time has elapsed to or beyond the libusb timeout)
+	if (time has elapsed to or beyond the libusbx timeout)
 		libusb_handle_events_timeout(ctx, &zero_tv);
 	// handle events from other sources here
 }
@@ -632,7 +632,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 libusb at
+ * The above complication with having to track time and call into libusbx 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
@@ -644,18 +644,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
- *   - libusb v1.0.5 or newer
+ *   - libusbx 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 libusb
+// initialise libusbx
 
 libusb_get_pollfds(ctx)
 while (user has not requested application exit) {
-	poll(on libusb file descriptors plus any other event sources of interest,
+	poll(on libusbx file descriptors plus any other event sources of interest,
 		using any timeout that you like)
-	if (poll() indicated activity on libusb file descriptors)
+	if (poll() indicated activity on libusbx file descriptors)
 		libusb_handle_events_timeout(ctx, &zero_tv);
 	// handle events from other sources here
 }
@@ -665,7 +665,7 @@ 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 libusb which may have time-based
+ * and <em>any future platforms supported by libusbx which may have time-based
  * event requirements</em>). The resultant problems will likely appear as
  * strange bugs in your application.
  *
@@ -678,7 +678,7 @@ while (user has not requested application exit) {
  *
  * \subsection fdsetchange Changes in the file descriptor set
  *
- * The set of file descriptors that libusb uses as event sources may change
+ * The set of file descriptors that libusbx 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().
@@ -699,10 +699,10 @@ while (user has not requested application exit) {
 
 /** \page mtasync Multi-threaded applications and asynchronous I/O
  *
- * libusb is a thread-safe library, but extra considerations must be applied
- * to applications which interact with libusb from multiple threads.
+ * libusbx is a thread-safe library, but extra considerations must be applied
+ * to applications which interact with libusbx from multiple threads.
  *
- * The underlying issue that must be addressed is that all libusb I/O
+ * The underlying issue that must be addressed is that all libusbx 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
@@ -716,7 +716,7 @@ while (user has not requested application exit) {
  *
  * 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 libusb
+ * synchronous interface on top of the asynchronous interface (and libusbx
  * does something similar, albeit more advanced due to the complications
  * explained on this page).
  *
@@ -739,7 +739,7 @@ void myfunc() {
 	libusb_submit_transfer(transfer);
 
 	while (!completed) {
-		poll(libusb file descriptors, 120*1000);
+		poll(libusbx file descriptors, 120*1000);
 		if (poll indicates activity)
 			libusb_handle_events_timeout(ctx, &zero_tv);
 	}
@@ -765,13 +765,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 libusb offers the scheme
+ * impact the capabilities of the library, so libusbx 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 - libusb hides this headache from you.
+ * synchronous I/O functions - libusbx hides this headache from you.
  *
  * \section Using libusb_handle_events() from multiple threads
  *
@@ -817,7 +817,7 @@ void myfunc() {
  *
  * \section eventlock The events lock
  *
- * The problem is when we consider the fact that libusb exposes file
+ * The problem is when we consider the fact that libusbx 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
  * libusb's back. If you do take libusb's file descriptors and pass them to
@@ -827,7 +827,7 @@ void myfunc() {
  * 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 libusb file descriptors,
+ * You must take the events lock before polling libusbx 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().
  *
@@ -838,7 +838,7 @@ void myfunc() {
 \code
 	libusb_lock_events(ctx);
 	while (!completed) {
-		poll(libusb file descriptors, 120*1000);
+		poll(libusbx file descriptors, 120*1000);
 		if (poll indicates activity)
 			libusb_handle_events_timeout(ctx, &zero_tv);
 	}
@@ -854,7 +854,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, libusb offers you a mechanism to determine when another
+ * To solve this, libusbx 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).
@@ -880,7 +880,7 @@ if (libusb_try_lock_events(ctx) == 0) {
 			libusb_unlock_events(ctx);
 			goto retry;
 		}
-		poll(libusb file descriptors, 120*1000);
+		poll(libusbx file descriptors, 120*1000);
 		if (poll indicates activity)
 			libusb_handle_events_locked(ctx, 0);
 	}
@@ -926,8 +926,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 libusb is still happy for your
- *    thread to be performing event handling. Sometimes, libusb needs to
+ * -# libusb_event_handling_ok() checks that libusbx is still happy for your
+ *    thread to be performing event handling. Sometimes, libusbx 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.
@@ -942,7 +942,7 @@ printf("completed!\n");
  *    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 libusb can do this
+ * blocked on libusb_wait_for_event(). This is because libusbx 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).
@@ -966,14 +966,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.
  *
- * libusb handles these issues internally, so application developers do not
+ * libusbx 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, libusb opens an internal pipe, and it adds the read
+ * -# During initialization, libusbx 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(), libusb writes some dummy data on this control pipe.
- *    This immediately interrupts the event handler. libusb also records
+ * -# During libusb_close(), libusbx writes some dummy data on this control pipe.
+ *    This immediately interrupts the event handler. libusbx 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
@@ -988,7 +988,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(), libusb can safely remove
+ * -# With the events lock held inside libusb_close(), libusbx 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
@@ -1005,7 +1005,7 @@ printf("completed!\n");
  * call to libusb_open():
  *
  * -# The device is opened and a file descriptor is added to the poll set.
- * -# libusb sends some dummy data on the control pipe, and records that it
+ * -# libusbx 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
@@ -1200,7 +1200,7 @@ out:
 }
 
 /** \ingroup asyncio
- * Allocate a libusb transfer with a specified number of isochronous packet
+ * Allocate a libusbx 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().
@@ -1511,7 +1511,7 @@ 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 libusb event sources at any one time.
+ * only one thread is monitoring libusbx 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 libusb's file descriptors directly.
@@ -1554,7 +1554,7 @@ 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 libusb event sources at any one time.
+ * monitoring libusbx 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 libusb's file descriptors directly.
@@ -1601,7 +1601,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, libusb needs to temporarily pause all event handlers, and this
+ * Sometimes, libusbx 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.
  *
@@ -1979,7 +1979,7 @@ static int get_next_timeout(libusb_context *ctx, struct timeval *tv,
 /** \ingroup poll
  * Handle any pending events.
  *
- * libusb determines "pending events" by checking if any timeouts have expired
+ * libusbx 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
@@ -2169,7 +2169,7 @@ int API_EXPORTED libusb_handle_events_locked(libusb_context *ctx,
  * poll()/select() timeout accordingly so that you can make a call into the
  * library at that time.
  *
- * Some platforms supported by libusb do not come with this baggage - any
+ * Some platforms supported by libusbx 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
@@ -2178,10 +2178,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 libusb at times determined by
+ * \returns 0 if you must call into libusbx 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 libusb file descriptors for event handling"
+ * \see \ref pollmain "Polling libusbx file descriptors for event handling"
  */
 int API_EXPORTED libusb_pollfds_handle_timeouts(libusb_context *ctx)
 {
@@ -2195,21 +2195,21 @@ int API_EXPORTED libusb_pollfds_handle_timeouts(libusb_context *ctx)
 }
 
 /** \ingroup poll
- * Determine the next internal timeout that libusb needs to handle. You only
+ * Determine the next internal timeout that libusbx needs to handle. You only
  * need to use this function if you are calling poll() or select() or similar
  * 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. libusb needs to be
+ * long to wait for select() or poll() to return results. libusbx 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 libusb can handle the timeout.
+ * (perhaps in non-blocking mode) so that libusbx can handle the timeout.
  *
  * This function may return 1 (success) and an all-zero timeval. If this is
- * the case, it indicates that libusb has a timeout that has already expired
+ * the case, it indicates that libusbx 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.
  *
@@ -2218,7 +2218,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 libusb must be called into in order to process timeout events
+ * clock in which libusbx 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
  */
@@ -2285,7 +2285,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 libusb uses as an event source.
+ * that libusbx uses as an event source.
  *
  * To remove notifiers, pass NULL values for the function pointers.
  *
@@ -2363,7 +2363,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 libusb event sources.
+ * as libusbx event sources.
  *
  * The returned list is NULL-terminated and should be freed with free() when
  * done. The actual list contents must not be touched.
diff --git a/libusb/libusb-1.0.rc b/libusb/libusb-1.0.rc
index a59a430..1aba015 100644
--- a/libusb/libusb-1.0.rc
+++ b/libusb/libusb-1.0.rc
@@ -36,7 +36,7 @@ BEGIN
 		BLOCK "040904b0"
 		BEGIN
 			VALUE "Comments", "\0"
-			VALUE "CompanyName", "libusb.org\0"
+			VALUE "CompanyName", "libusbx.org\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 4141a8e..8e29ca7 100644
--- a/libusb/libusb.h
+++ b/libusb/libusb.h
@@ -1,7 +1,7 @@
 /*
- * Public libusb header file
- * Copyright (C) 2007-2008 Daniel Drake <dsd@gentoo.org>
- * Copyright (c) 2001 Johannes Erdfelt <johannes@erdfelt.com>
+ * Public libusbx header file
+ * Copyright © 2007-2008 Daniel Drake <dsd@gentoo.org>
+ * Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -54,7 +54,7 @@ typedef unsigned __int32  uint32_t;
 #endif
 
 /* 'interface' might be defined as a macro on Windows, so we need to
- * undefine it so as not to break the current libusb API, because
+ * undefine it so as not to break the current libusbx 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. */
@@ -74,7 +74,7 @@ typedef unsigned __int32  uint32_t;
  * convention</em> (calling convention: the manner in which parameters are
  * passed to funcions in the generated assembly code).
  *
- * Matching the Windows API itself, libusb uses the WINAPI convention (which
+ * Matching the Windows API itself, libusbx 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
@@ -82,7 +82,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 libusb callbacks with this LIBUSB_CALL
+ * all functions which you use as libusbx callbacks with this LIBUSB_CALL
  * annotation, so that they too get compiled for the correct calling
  * convention.
  *
@@ -90,7 +90,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 libusb
+/* LIBUSB_CALL must be defined on both definition and declaration of libusbx
  * 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
@@ -486,7 +486,7 @@ struct libusb_endpoint_descriptor {
 	/** For audio devices only: the address if the synch endpoint */
 	uint8_t  bSynchAddress;
 
-	/** Extra descriptors. If libusb encounters unknown endpoint descriptors,
+	/** Extra descriptors. If libusbx encounters unknown endpoint descriptors,
 	 * it will store them here, should you wish to parse them. */
 	const unsigned char *extra;
 
@@ -536,7 +536,7 @@ struct libusb_interface_descriptor {
 	 * by the bNumEndpoints field. */
 	const struct libusb_endpoint_descriptor *endpoint;
 
-	/** Extra descriptors. If libusb encounters unknown interface descriptors,
+	/** Extra descriptors. If libusbx encounters unknown interface descriptors,
 	 * it will store them here, should you wish to parse them. */
 	const unsigned char *extra;
 
@@ -594,7 +594,7 @@ struct libusb_config_descriptor {
 	 * this array is determined by the bNumInterfaces field. */
 	const struct libusb_interface *interface;
 
-	/** Extra descriptors. If libusb encounters unknown configuration
+	/** Extra descriptors. If libusbx encounters unknown configuration
 	 * descriptors, it will store them here, should you wish to parse them. */
 	const unsigned char *extra;
 
@@ -632,23 +632,23 @@ struct libusb_control_setup {
 
 #define LIBUSB_CONTROL_SETUP_SIZE (sizeof(struct libusb_control_setup))
 
-/* libusb */
+/* libusbx */
 
 struct libusb_context;
 struct libusb_device;
 struct libusb_device_handle;
 
 /** \ingroup lib
- * Structure representing a libusb session. The concept of individual libusb
+ * Structure representing a libusbx session. The concept of individual libusbx
  * 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 libusb users - for example
+ * interference between the individual libusbx 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 libusb
+ * If your application is guaranteed to only ever include a single libusbx
  * 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.
@@ -706,7 +706,7 @@ enum libusb_speed {
 };
 
 /** \ingroup misc
- * Error codes. Most libusb functions return 0 on success or one of these
+ * Error codes. Most libusbx functions return 0 on success or one of these
  * codes on failure.
  * You can call \ref libusb_error_name() to retrieve a string representation
  * of an error code.
@@ -845,7 +845,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. libusb will call this function later, when the transfer has
+ * structure. libusbx 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.
diff --git a/libusb/libusbi.h b/libusb/libusbi.h
index 335df11..9a978ad 100644
--- a/libusb/libusbi.h
+++ b/libusb/libusbi.h
@@ -1,7 +1,7 @@
 /*
- * Internal header for libusb
- * Copyright (C) 2007-2009 Daniel Drake <dsd@gentoo.org>
- * Copyright (c) 2001 Johannes Erdfelt <johannes@erdfelt.com>
+ * Internal header for libusbx
+ * Copyright © 2007-2009 Daniel Drake <dsd@gentoo.org>
+ * Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -33,11 +33,11 @@
 
 #include <libusb.h>
 
-/* Inside the libusb code, mark all public functions as follows:
+/* Inside the libusbx 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 libusb public header, mark all declarations as:
+ * In the libusbx public header, mark all declarations as:
  *   return_type LIBUSB_CALL function_name(params);
  */
 #define API_EXPORTED LIBUSB_CALL DEFAULT_VISIBILITY
@@ -433,7 +433,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 libusb user initializes the library
+	 * This function is called when a libusbx user initializes the library
 	 * prior to use.
 	 *
 	 * Return 0 on success, or a LIBUSB_ERROR code on failure.
@@ -463,7 +463,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 libusb already
+	 * usbi_get_device_by_session_id(). This function checks if libusbx already
 	 * knows about the device, and if so, it provides you with a libusb_device
 	 * structure for it.
 	 *
@@ -505,7 +505,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 libusb that it
+	 * without hiccup. This is also a good place to inform libusbx that it
 	 * should monitor certain file descriptors related to this device -
 	 * see the usbi_add_pollfd() function.
 	 *
@@ -529,7 +529,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
-	 * libusb of any file descriptors associated with this device that should
+	 * libusbx 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.
@@ -614,7 +614,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
-	 * libusb to retrieve the information through a standard control transfer.
+	 * libusbx to retrieve the information through a standard control transfer.
 	 *
 	 * This function must be non-blocking.
 	 * Return:
@@ -811,7 +811,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 libusb
+	 * This function might seem a bit out of place. It is used when libusbx
 	 * 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.
@@ -893,4 +893,3 @@ extern const struct usbi_os_backend openbsd_backend;
 extern const struct usbi_os_backend windows_backend;
 
 #endif
-
diff --git a/libusb/os/darwin_usb.c b/libusb/os/darwin_usb.c
index 60d2e03..e6e514e 100644
--- a/libusb/os/darwin_usb.c
+++ b/libusb/os/darwin_usb.c
@@ -1,6 +1,6 @@
 /*
- * darwin backend for libusb 1.0
- * Copyright (C) 2008-2011 Nathan Hjelm <hjelmn@users.sourceforge.net>
+ * darwin backend for libusbx 1.0
+ * Copyright © 2008-2011 Nathan Hjelm <hjelmn@users.sourceforge.net>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -1268,7 +1268,7 @@ static int submit_bulk_transfer(struct usbi_transfer *itransfer) {
 
   IOReturn               ret;
   uint8_t                transferType;
-  /* None of the values below are used in libusb for bulk transfers */
+  /* None of the values below are used in libusbx for bulk transfers */
   uint8_t                direction, number, interval, pipeRef, iface;
   uint16_t               maxPacketSize;
 
@@ -1343,7 +1343,7 @@ static int submit_iso_transfer(struct usbi_transfer *itransfer) {
       return LIBUSB_ERROR_NO_MEM;
   }
 
-  /* copy the frame list from the libusb descriptor (the structures differ only is member order) */
+  /* copy the frame list from the libusbx 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;
 
@@ -1412,7 +1412,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 libusb control block */
+  /* data is stored after the libusbx control block */
   tpriv->req.pData             = transfer->buffer + LIBUSB_CONTROL_SETUP_SIZE;
   tpriv->req.completionTimeout = transfer->timeout;
   tpriv->req.noDataTimeout     = transfer->timeout;
@@ -1751,4 +1751,3 @@ const struct usbi_os_backend darwin_backend = {
 	.transfer_priv_size = sizeof(struct darwin_transfer_priv),
 	.add_iso_packet_size = 0,
 };
-
diff --git a/libusb/os/darwin_usb.h b/libusb/os/darwin_usb.h
index 59d0a69..8899297 100644
--- a/libusb/os/darwin_usb.h
+++ b/libusb/os/darwin_usb.h
@@ -1,6 +1,6 @@
 /*
- * darwin backend for libusb 1.0
- * Copyright (C) 2008-2009 Nathan Hjelm <hjelmn@users.sourceforge.net>
+ * darwin backend for libusbx 1.0
+ * Copyright © 2008-2009 Nathan Hjelm <hjelmn@users.sourceforge.net>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
index 8713a09..f2b312d 100644
--- a/libusb/os/linux_usbfs.c
+++ b/libusb/os/linux_usbfs.c
@@ -1,7 +1,7 @@
 /*
- * Linux usbfs backend for libusb
- * Copyright (C) 2007-2009 Daniel Drake <dsd@gentoo.org>
- * Copyright (c) 2001 Johannes Erdfelt <johannes@erdfelt.com>
+ * Linux usbfs backend for libusbx
+ * Copyright © 2007-2009 Daniel Drake <dsd@gentoo.org>
+ * Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -341,7 +341,7 @@ static int op_init(struct libusb_context *ctx)
 			if (strncmp(entry->d_name, "usb", 3) != 0)
 				continue;
 
-			/* Check for the files libusb needs from sysfs. */
+			/* Check for the files libusbx needs from sysfs. */
 			has_busnum = sysfs_has_file(entry->d_name, "busnum");
 			has_devnum = sysfs_has_file(entry->d_name, "devnum");
 			has_descriptors = sysfs_has_file(entry->d_name, "descriptors");
@@ -1162,13 +1162,13 @@ static int op_open(struct libusb_device_handle *handle)
 	hpriv->fd = open(filename, O_RDWR);
 	if (hpriv->fd < 0) {
 		if (errno == EACCES) {
-			usbi_err(HANDLE_CTX(handle), "libusb couldn't open USB device %s: "
+			usbi_err(HANDLE_CTX(handle), "libusbx couldn't open USB device %s: "
 				"Permission denied.", filename);
 			usbi_err(HANDLE_CTX(handle),
-				"libusb requires write access to USB device nodes.");
+				"libusbx requires write access to USB device nodes.");
 			return LIBUSB_ERROR_ACCESS;
 		} else if (errno == ENOENT) {
-			usbi_err(HANDLE_CTX(handle), "libusb couldn't open USB device %s: "
+			usbi_err(HANDLE_CTX(handle), "libusbx couldn't open USB device %s: "
 				"No such file or directory.", filename);
 			return LIBUSB_ERROR_NO_DEVICE;
 		} else {
@@ -1608,7 +1608,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 libusb will be using
+			 *    discarded URBs are reaped, otherwise libusbx will be using
 			 *    freed memory.
 			 *  - the earlier URBs may have completed successfully and we do
 			 *    not want to throw away any data.
@@ -1766,7 +1766,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 libusb will be using
+			 *    discarded URBs are reaped, otherwise libusbx will be using
 			 *    freed memory.
 			 *  - the earlier URBs may have completed successfully and we do
 			 *    not want to throw away any data.
@@ -1942,7 +1942,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 libusb reports the total amount of
+		 * (closing any holes), so that libusbx reports the total amount of
 		 * transferred data and presents it in a contiguous chunk.
 		 */
 		if (urb->actual_length > 0) {
@@ -2376,4 +2376,3 @@ const struct usbi_os_backend linux_usbfs_backend = {
 	.transfer_priv_size = sizeof(struct linux_transfer_priv),
 	.add_iso_packet_size = 0,
 };
-
diff --git a/libusb/os/linux_usbfs.h b/libusb/os/linux_usbfs.h
index 487acb5..326f372 100644
--- a/libusb/os/linux_usbfs.h
+++ b/libusb/os/linux_usbfs.h
@@ -1,7 +1,7 @@
 /*
  * usbfs header structures
- * Copyright (C) 2007 Daniel Drake <dsd@gentoo.org>
- * Copyright (c) 2001 Johannes Erdfelt <johannes@erdfelt.com>
+ * Copyright © 2007 Daniel Drake <dsd@gentoo.org>
+ * Copyright © 2001 Johannes Erdfelt <johannes@erdfelt.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
diff --git a/libusb/os/openbsd_usb.c b/libusb/os/openbsd_usb.c
index bbafa82..d0792b3 100644
--- a/libusb/os/openbsd_usb.c
+++ b/libusb/os/openbsd_usb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011 Martin Pieuchot <mpi@openbsd.org>
+ * Copyright © 2011 Martin Pieuchot <mpi@openbsd.org>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -624,7 +624,7 @@ _sync_control_transfer(struct usbi_transfer *itransfer)
 
 	req.ucr_request.bmRequestType = setup->bmRequestType;
 	req.ucr_request.bRequest = setup->bRequest;
-	/* Don't use USETW, libusb already deals with the endianness */
+	/* Don't use USETW, libusbx 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 c997c81..99cc5e1 100644
--- a/libusb/os/poll_windows.c
+++ b/libusb/os/poll_windows.c
@@ -1,6 +1,6 @@
 /*
  * poll_windows: poll compatibility wrapper for Windows
- * Copyright (C) 2009-2010 Pete Batard <pbatard@gmail.com>
+ * Copyright © 2009-2010 Pete Batard <pbatard@gmail.com>
  * With contributions from Michael Plante, Orin Eman et al.
  * Parts of poll implementation from libusb-win32, by Stephan Meyer et al.
  *
@@ -21,7 +21,7 @@
  */
 
 /*
- * poll() and pipe() Windows compatibility layer for libusb 1.0
+ * poll() and pipe() Windows compatibility layer for libusbx 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.
@@ -263,7 +263,7 @@ void exit_polling(void)
 
 /*
  * Create a fake pipe.
- * As libusb only uses pipes for signaling, all we need from a pipe is an
+ * As libusbx 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/poll_windows.h b/libusb/os/poll_windows.h
index 4cc345b..2aee946 100644
--- a/libusb/os/poll_windows.h
+++ b/libusb/os/poll_windows.h
@@ -1,6 +1,6 @@
 /*
  * Windows compat: POSIX compatibility wrapper
- * Copyright (C) 2009-2010 Pete Batard <pbatard@gmail.com>
+ * Copyright © 2009-2010 Pete Batard <pbatard@gmail.com>
  * With contributions from Michael Plante, Orin Eman et al.
  * Parts of poll implementation from libusb-win32, by Stephan Meyer et al.
  *
@@ -117,4 +117,3 @@ do {                                                    \
 	}                                                   \
 } while (0)
 #endif
-
diff --git a/libusb/os/threads_posix.c b/libusb/os/threads_posix.c
index 60c57cf..fb040ce 100644
--- a/libusb/os/threads_posix.c
+++ b/libusb/os/threads_posix.c
@@ -1,8 +1,8 @@
 /*
- * libusb synchronization using POSIX Threads
+ * libusbx synchronization using POSIX Threads
  *
- * Copyright (C) 2011 Vitali Lovich <vlovich@aliph.com>
- * Copyright (C) 2011 Peter Stuge <peter@stuge.se>
+ * Copyright © 2011 Vitali Lovich <vlovich@aliph.com>
+ * Copyright © 2011 Peter Stuge <peter@stuge.se>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
diff --git a/libusb/os/threads_posix.h b/libusb/os/threads_posix.h
index 9752208..db4de28 100644
--- a/libusb/os/threads_posix.h
+++ b/libusb/os/threads_posix.h
@@ -1,7 +1,7 @@
 /*
- * libusb synchronization using POSIX Threads
+ * libusbx synchronization using POSIX Threads
  *
- * Copyright (C) 2010 Peter Stuge <peter@stuge.se>
+ * Copyright © 2010 Peter Stuge <peter@stuge.se>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
diff --git a/libusb/os/threads_windows.c b/libusb/os/threads_windows.c
index fe2bfc1..c4fa489 100644
--- a/libusb/os/threads_windows.c
+++ b/libusb/os/threads_windows.c
@@ -1,7 +1,7 @@
 /*
- * libusb synchronization on Microsoft Windows
+ * libusbx synchronization on Microsoft Windows
  *
- * Copyright (C) 2010 Michael Plante <michael.plante@gmail.com>
+ * Copyright © 2010 Michael Plante <michael.plante@gmail.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -204,4 +204,3 @@ int usbi_cond_timedwait(usbi_cond_t *cond,
 
 	return usbi_cond_intwait(cond, mutex, millis);
 }
-
diff --git a/libusb/os/threads_windows.h b/libusb/os/threads_windows.h
index 7bb144a..764a98c 100644
--- a/libusb/os/threads_windows.h
+++ b/libusb/os/threads_windows.h
@@ -1,7 +1,7 @@
 /*
- * libusb synchronization on Microsoft Windows
+ * libusbx synchronization on Microsoft Windows
  *
- * Copyright (C) 2010 Michael Plante <michael.plante@gmail.com>
+ * Copyright © 2010 Michael Plante <michael.plante@gmail.com>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -83,4 +83,3 @@ int usbi_cond_broadcast(usbi_cond_t *cond);
 int usbi_cond_signal(usbi_cond_t *cond);
 
 #endif /* LIBUSB_THREADS_WINDOWS_H */
-
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index 6552ed6..908206e 100644
--- a/libusb/os/windows_usb.c
+++ b/libusb/os/windows_usb.c
@@ -1,6 +1,6 @@
 /*
- * windows backend for libusb 1.0
- * Copyright (c) 2009-2010 Pete Batard <pbatard@gmail.com>
+ * windows backend for libusbx 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
  * Hash table functions adapted from glibc, by Ulrich Drepper et al.
@@ -22,7 +22,7 @@
  */
 
 // COMPILATION OPTIONS:
-// - Should libusb automatically claim (and release) the interfaces it requires?
+// - Should libusbx automatically claim (and release) the interfaces it requires?
 #define AUTO_CLAIM
 // - Forces instant overlapped completion on timeouts: can prevents extensive
 //   wait in poll, after a timeout, but might affect subsequent API calls.
@@ -699,7 +699,7 @@ static void auto_release(struct usbi_transfer *itransfer)
 
 
 /*
- * init: libusb backend init function
+ * init: libusbx 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 LibUSB's "bus". Note that bus is zero indexed.
@@ -975,7 +975,7 @@ static int cache_config_descriptors(struct libusb_device *dev, HANDLE hub_handle
 }
 
 /*
- * Populate a libusb device structure
+ * Populate a libusbx device structure
  */
 static int init_device(struct libusb_device* dev, struct libusb_device* parent_dev,
 					   uint8_t port_number, char* device_id, DWORD devinst)
@@ -1179,7 +1179,7 @@ static int set_composite_interface(struct libusb_context* ctx, struct libusb_dev
 }
 
 /*
- * get_device_list: libusb backend device enumeration function
+ * get_device_list: libusbx backend device enumeration function
  */
 static int windows_get_device_list(struct libusb_context *ctx, struct discovered_devs **_discdevs)
 {
@@ -1336,7 +1336,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, "libusb will not be able to access it.");
+						usbi_info(ctx, "libusbx 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);
@@ -1522,7 +1522,7 @@ static int windows_get_device_list(struct libusb_context *ctx, struct discovered
 }
 
 /*
- * exit: libusb backend deinitialization function
+ * exit: libusbx backend deinitialization function
  */
 static void windows_exit(void)
 {
@@ -2941,7 +2941,7 @@ static int composite_submit_control_transfer(struct usbi_transfer *itransfer)
 		}
 	}
 
-	usbi_err(ctx, "no libusb supported interfaces to complete request");
+	usbi_err(ctx, "no libusbx 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 4fe4916..d3fc59f 100644
--- a/libusb/os/windows_usb.h
+++ b/libusb/os/windows_usb.h
@@ -1,6 +1,6 @@
 /*
- * Windows backend for libusb 1.0
- * Copyright (C) 2009-2010 Pete Batard <pbatard@gmail.com>
+ * Windows backend for libusbx 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
  * Major code testing contribution by Xiaofan Chen
diff --git a/libusb/sync.c b/libusb/sync.c
index 8eed47b..47445b7 100644
--- a/libusb/sync.c
+++ b/libusb/sync.c
@@ -1,6 +1,6 @@
 /*
- * Synchronous I/O functions for libusb
- * Copyright (C) 2007-2008 Daniel Drake <dsd@gentoo.org>
+ * Synchronous I/O functions for libusbx
+ * Copyright © 2007-2008 Daniel Drake <dsd@gentoo.org>
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -228,9 +228,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.
- * libusb may have to split your transfer into a number of chunks to satisfy
+ * libusbx 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. libusb is careful not to lose any data
+ * the first few chunks have completed. libusbx 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.
  *
@@ -276,9 +276,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.
- * libusb may have to split your transfer into a number of chunks to satisfy
+ * libusbx 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. libusb is careful not to lose any data
+ * the first few chunks have completed. libusbx 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.
  *
@@ -311,4 +311,3 @@ int API_EXPORTED libusb_interrupt_transfer(
 	return do_sync_bulk_transfer(dev_handle, endpoint, data, length,
 		transferred, timeout, LIBUSB_TRANSFER_TYPE_INTERRUPT);
 }
-