/*
- * 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
*
* \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.
* 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.
* above.
*
* Instead of providing which functions that block until the I/O has complete,
- * libusb's asynchronous interface presents non-blocking functions which
+ * libusbx'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
* 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
* results are handled. This becomes particularly obvious when you want to
* submit a second transfer based on the results of an earlier transfer.
*
- * Internally, libusb's synchronous interface is expressed in terms of function
+ * Internally, libusbx's synchronous interface is expressed in terms of function
* calls to the asynchronous interface.
*
* For details on how to use the asynchronous API, see the
* 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.
/**
* @defgroup asyncio Asynchronous device I/O
*
- * This page details libusb's asynchronous (non-blocking) API for USB device
+ * This page details libusbx's asynchronous (non-blocking) API for USB device
* I/O. This interface is very powerful but is also quite complex - you will
* need to read this page carefully to understand the necessary considerations
* and issues surrounding use of this interface. Simplistic applications
*
* \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.
* -# <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
*
* 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.
*
* 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
*
* 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.
*
* \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
* 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
- * libusb's file descriptors to your poll()/select() calls, and when activity
+ * libusbx's file descriptors to your poll()/select() calls, and when activity
* is detected on such descriptors you know it is time to call
* libusb_handle_events().
*
- * There is one final event handling complication. 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
- * 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
+ * this requires that libusbx is called into at or after the timeout so that
+ * the timeout can be handled. So, in addition to considering libusbx's file
+ * 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.
*
/**
* @defgroup poll Polling and timing
*
- * This page documents libusb's functions for polling events and timing.
+ * This page documents libusbx's functions for polling events and timing.
* These functions are only necessary for users of the
* \ref asyncio "asynchronous API". If you are only using the simpler
* \ref syncio "synchronous API" then you do not need to ever call these
*
* 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.
*
*
* \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
*
* 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
- * detect activity on libusb's file descriptors, you call
+ * take a set of file descriptors from libusbx and monitor those too. When you
+ * detect activity on libusbx'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
* 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
}
*
* \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
* - 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
}
*
* 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.
*
* You can use the libusb_pollfds_handle_timeouts() function to do a runtime
* check to see if it is safe to ignore the time-based event complications.
- * If your application has taken the shortcut of ignoring libusb's next timeout
+ * If your application has taken the shortcut of ignoring libusbx's next timeout
* in your main loop, then you are advised to check the return value of
* libusb_pollfds_handle_timeouts() during application startup, and to abort
* if the platform does suffer from these timing complications.
*
* \subsection fdsetchange Changes in the file descriptor set
*
- * The set of file descriptors that 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().
/** \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
* asynchonrous interface, therefore the same considerations apply.
*
* The issue is that if two or more threads are concurrently calling poll()
- * or select() on libusb's file descriptors then only one of those threads
+ * or select() on libusbx's file descriptors then only one of those threads
* will be woken up when an event arrives. The others will be completely
* oblivious that anything has happened.
*
* Consider the following pseudo-code, which submits an asynchronous transfer
* then waits for its completion. This style is one way you could implement a
- * synchronous interface on top of the asynchronous interface (and 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).
*
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);
}
* The poll() loop has a long timeout to minimize CPU usage during situations
* when nothing is happening (it could reasonably be unlimited).
*
- * If this is the only thread that is polling libusb's file descriptors, there
+ * If this is the only thread that is polling libusbx's file descriptors, there
* is no problem: there is no danger that another thread will swallow up the
* event that we are interested in. On the other hand, if there is another
* thread polling the same descriptors, there is a chance that it will receive
*
* 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
*
*
* \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
+ * libusbx's back. If you do take libusbx's file descriptors and pass them to
* poll()/select() yourself, you need to be aware of the associated issues.
*
* The first concept to be introduced is the events lock. The events lock
* is used to serialize threads that want to handle events, such that only
* one thread is handling events at any one time.
*
- * You must take the events lock before polling 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().
*
\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);
}
* 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).
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);
}
* 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.
* libusb_handle_events_timeout() that you can call while holding the
* events lock. libusb_handle_events_timeout() itself implements similar
* logic to the above, so be sure not to call it when you are
- * "working behind libusb's back", as is the case here.
+ * "working behind libusbx's back", as is the case here.
* -# libusb_event_handler_active() determines if someone is currently
* holding the events lock
*
* You might be wondering why there is no function to wake up all threads
- * blocked on libusb_wait_for_event(). This is because 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).
*
* The above explanation should be enough to get you going, but if you're
* really thinking through the issues then you may be left with some more
- * questions regarding libusb's internals. If you're curious, read on, and if
+ * questions regarding libusbx's internals. If you're curious, read on, and if
* not, skip to the next section to avoid confusing yourself!
*
* The immediate question that may spring to mind is: what if one thread
* 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
* 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
* 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
*
* The above may seem a little complicated, but hopefully I have made it clear
* why such complications are necessary. Also, do not forget that this only
- * applies to applications that take libusb's file descriptors and integrate
+ * applies to applications that take libusbx's file descriptors and integrate
* them into their own polling loops.
*
* You may decide that it is OK for your multi-threaded application to ignore
/* if we have no other flying transfers, start the list with this one */
if (list_empty(&ctx->flying_transfers)) {
list_add(&transfer->list, &ctx->flying_transfers);
- if (timerisset(timeout))
- r = 1;
goto out;
}
/* if we have infinite timeout, append to end of list */
if (!timerisset(timeout)) {
list_add_tail(&transfer->list, &ctx->flying_transfers);
+ /* first is irrelevant in this case */
goto out;
}
(cur_tv->tv_sec == timeout->tv_sec &&
cur_tv->tv_usec > timeout->tv_usec)) {
list_add_tail(&transfer->list, &cur->list);
- r = first;
goto out;
}
first = 0;
}
+ /* first is 0 at this stage (list not empty) */
/* otherwise we need to be inserted at the end */
list_add_tail(&transfer->list, &ctx->flying_transfers);
out:
+#ifdef USBI_TIMERFD_AVAILABLE
+ if (first && usbi_using_timerfd(ctx) && timerisset(timeout)) {
+ /* if this transfer has the lowest timeout of all active transfers,
+ * rearm the timerfd with this transfer's timeout */
+ const struct itimerspec it = { {0, 0},
+ { transfer->timeout.tv_sec, transfer->timeout.tv_usec * 1000 } };
+ usbi_dbg("arm timerfd for timeout in %dms (first in line)",
+ USBI_TRANSFER_TO_LIBUSB_TRANSFER(transfer)->timeout);
+ r = timerfd_settime(ctx->timerfd, TFD_TIMER_ABSTIME, &it, NULL);
+ if (r < 0) {
+ usbi_warn(ctx, "failed to arm first timerfd (error %d)", r);
+ r = LIBUSB_ERROR_OTHER;
+ }
+ }
+#else
+ UNUSED(first);
+#endif
+
usbi_mutex_unlock(&ctx->flying_transfers_lock);
return r;
}
/** \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().
+ sizeof(struct libusb_transfer)
+ (sizeof(struct libusb_iso_packet_descriptor) * iso_packets)
+ os_alloc_size;
- struct usbi_transfer *itransfer = malloc(alloc_size);
+ struct usbi_transfer *itransfer = calloc(1, alloc_size);
if (!itransfer)
return NULL;
- memset(itransfer, 0, alloc_size);
itransfer->num_iso_packets = iso_packets;
usbi_mutex_init(&itransfer->lock, NULL);
return USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
free(itransfer);
}
+#ifdef USBI_TIMERFD_AVAILABLE
+static int disarm_timerfd(struct libusb_context *ctx)
+{
+ const struct itimerspec disarm_timer = { { 0, 0 }, { 0, 0 } };
+ int r;
+
+ usbi_dbg("");
+ r = timerfd_settime(ctx->timerfd, 0, &disarm_timer, NULL);
+ if (r < 0)
+ return LIBUSB_ERROR_OTHER;
+ else
+ return 0;
+}
+
+/* iterates through the flying transfers, and rearms the timerfd based on the
+ * next upcoming timeout.
+ * must be called with flying_list locked.
+ * returns 0 if there was no timeout to arm, 1 if the next timeout was armed,
+ * or a LIBUSB_ERROR code on failure.
+ */
+static int arm_timerfd_for_next_timeout(struct libusb_context *ctx)
+{
+ struct usbi_transfer *transfer;
+
+ list_for_each_entry(transfer, &ctx->flying_transfers, list, struct usbi_transfer) {
+ struct timeval *cur_tv = &transfer->timeout;
+
+ /* if we've reached transfers of infinite timeout, then we have no
+ * arming to do */
+ if (!timerisset(cur_tv))
+ goto disarm;
+
+ /* act on first transfer that is not already cancelled */
+ if (!(transfer->flags & USBI_TRANSFER_TIMED_OUT)) {
+ int r;
+ const struct itimerspec it = { {0, 0},
+ { cur_tv->tv_sec, cur_tv->tv_usec * 1000 } };
+ usbi_dbg("next timeout originally %dms", USBI_TRANSFER_TO_LIBUSB_TRANSFER(transfer)->timeout);
+ r = timerfd_settime(ctx->timerfd, TFD_TIMER_ABSTIME, &it, NULL);
+ if (r < 0)
+ return LIBUSB_ERROR_OTHER;
+ return 1;
+ }
+ }
+
+disarm:
+ return disarm_timerfd(ctx);
+}
+#else
+static int arm_timerfd_for_next_timeout(struct libusb_context *ctx)
+{
+ (void)ctx;
+ return 0;
+}
+#endif
+
/** \ingroup asyncio
* Submit a transfer. This function will fire off the USB transfer and then
* return immediately.
* \returns 0 on success
* \returns LIBUSB_ERROR_NO_DEVICE if the device has been disconnected
* \returns LIBUSB_ERROR_BUSY if the transfer has already been submitted.
+ * \returns LIBUSB_ERROR_NOT_SUPPORTED if the transfer flags are not supported
+ * by the operating system.
* \returns another LIBUSB_ERROR code on other failure
*/
int API_EXPORTED libusb_submit_transfer(struct libusb_transfer *transfer)
struct usbi_transfer *itransfer =
LIBUSB_TRANSFER_TO_USBI_TRANSFER(transfer);
int r;
- int first;
+ int updated_fds;
usbi_mutex_lock(&itransfer->lock);
itransfer->transferred = 0;
goto out;
}
- first = add_to_flying_list(itransfer);
+ r = add_to_flying_list(itransfer);
+ if (r)
+ goto out;
r = usbi_backend->submit_transfer(itransfer);
if (r) {
usbi_mutex_lock(&ctx->flying_transfers_lock);
list_del(&itransfer->list);
+ arm_timerfd_for_next_timeout(ctx);
usbi_mutex_unlock(&ctx->flying_transfers_lock);
}
-#ifdef USBI_TIMERFD_AVAILABLE
- else if (first && usbi_using_timerfd(ctx)) {
- /* if this transfer has the lowest timeout of all active transfers,
- * rearm the timerfd with this transfer's timeout */
- const struct itimerspec it = { {0, 0},
- { itransfer->timeout.tv_sec, itransfer->timeout.tv_usec * 1000 } };
- usbi_dbg("arm timerfd for timeout in %dms (first in line)", transfer->timeout);
- r = timerfd_settime(ctx->timerfd, TFD_TIMER_ABSTIME, &it, NULL);
- if (r < 0)
- r = LIBUSB_ERROR_OTHER;
- }
-#else
- (void)first;
-#endif
out:
+ updated_fds = (itransfer->flags & USBI_TRANSFER_UPDATED_FDS);
usbi_mutex_unlock(&itransfer->lock);
+ if (updated_fds)
+ usbi_fd_notification(ctx);
return r;
}
usbi_mutex_lock(&itransfer->lock);
r = usbi_backend->cancel_transfer(itransfer);
if (r < 0) {
- usbi_err(TRANSFER_CTX(transfer),
- "cancel transfer failed error %d", r);
+ if (r != LIBUSB_ERROR_NOT_FOUND)
+ usbi_err(TRANSFER_CTX(transfer),
+ "cancel transfer failed error %d", r);
+ else
+ usbi_dbg("cancel transfer failed error %d", r);
if (r == LIBUSB_ERROR_NO_DEVICE)
itransfer->flags |= USBI_TRANSFER_DEVICE_DISAPPEARED;
return r;
}
-#ifdef USBI_TIMERFD_AVAILABLE
-static int disarm_timerfd(struct libusb_context *ctx)
-{
- const struct itimerspec disarm_timer = { { 0, 0 }, { 0, 0 } };
- int r;
-
- usbi_dbg("");
- r = timerfd_settime(ctx->timerfd, 0, &disarm_timer, NULL);
- if (r < 0)
- return LIBUSB_ERROR_OTHER;
- else
- return 0;
-}
-
-/* iterates through the flying transfers, and rearms the timerfd based on the
- * next upcoming timeout.
- * must be called with flying_list locked.
- * returns 0 if there was no timeout to arm, 1 if the next timeout was armed,
- * or a LIBUSB_ERROR code on failure.
- */
-static int arm_timerfd_for_next_timeout(struct libusb_context *ctx)
-{
- struct usbi_transfer *transfer;
-
- list_for_each_entry(transfer, &ctx->flying_transfers, list, struct usbi_transfer) {
- struct timeval *cur_tv = &transfer->timeout;
-
- /* if we've reached transfers of infinite timeout, then we have no
- * arming to do */
- if (!timerisset(cur_tv))
- return 0;
-
- /* act on first transfer that is not already cancelled */
- if (!(transfer->flags & USBI_TRANSFER_TIMED_OUT)) {
- int r;
- const struct itimerspec it = { {0, 0},
- { cur_tv->tv_sec, cur_tv->tv_usec * 1000 } };
- usbi_dbg("next timeout originally %dms", USBI_TRANSFER_TO_LIBUSB_TRANSFER(transfer)->timeout);
- r = timerfd_settime(ctx->timerfd, TFD_TIMER_ABSTIME, &it, NULL);
- if (r < 0)
- return LIBUSB_ERROR_OTHER;
- return 1;
- }
- }
-
- return 0;
-}
-#else
-static int disarm_timerfd(struct libusb_context *ctx)
-{
- (void)ctx;
- return 0;
-}
-static int arm_timerfd_for_next_timeout(struct libusb_context *ctx)
-{
- (void)ctx;
- return 0;
-}
-#endif
-
/* Handle completion of a transfer (completion might be an error condition).
* This will invoke the user-supplied callback function, which may end up
* freeing the transfer. Therefore you cannot use the transfer structure
USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
struct libusb_context *ctx = TRANSFER_CTX(transfer);
uint8_t flags;
- int r;
+ int r = 0;
/* FIXME: could be more intelligent with the timerfd here. we don't need
* to disarm the timerfd if there was no timer running, and we only need
usbi_mutex_lock(&ctx->flying_transfers_lock);
list_del(&itransfer->list);
- r = arm_timerfd_for_next_timeout(ctx);
+ if (usbi_using_timerfd(ctx))
+ r = arm_timerfd_for_next_timeout(ctx);
usbi_mutex_unlock(&ctx->flying_transfers_lock);
-
- if (r < 0) {
+ if (usbi_using_timerfd(ctx) && (r < 0))
return r;
- } else if (r == 0) {
- r = disarm_timerfd(ctx);
- if (r < 0)
- return r;
- }
if (status == LIBUSB_TRANSFER_COMPLETED
&& transfer->flags & LIBUSB_TRANSFER_SHORT_NOT_OK) {
flags = transfer->flags;
transfer->status = status;
transfer->actual_length = itransfer->transferred;
+ usbi_dbg("transfer %p has callback %p", transfer, transfer->callback);
if (transfer->callback)
transfer->callback(transfer);
/* transfer might have been freed by the above call, do not use from
/** \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.
- * If you stick to libusb's event handling loop functions (e.g.
+ * which calls poll() or select() on libusbx's file descriptors directly.
+ * If you stick to libusbx's event handling loop functions (e.g.
* libusb_handle_events()) then you do not need to be concerned with this
* locking.
*
/** \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.
- * If you stick to libusb's event handling loop functions (e.g.
+ * which calls poll() or select() on libusbx's file descriptors directly.
+ * If you stick to libusbx's event handling loop functions (e.g.
* libusb_handle_events()) then you do not need to be concerned with this
* locking.
*
/** \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.
*
* events, then call libusb_wait_for_event().
*
* You only need to use this lock if you are developing an application
- * which calls poll() or select() on libusb's file descriptors directly,
+ * which calls poll() or select() on libusbx's file descriptors directly,
* <b>and</b> may potentially be handling events from 2 threads simultaenously.
- * If you stick to libusb's event handling loop functions (e.g.
+ * If you stick to libusbx's event handling loop functions (e.g.
* libusb_handle_events()) then you do not need to be concerned with this
* locking.
*
{
int r;
- r = disarm_timerfd(ctx);
- if (r < 0)
- return r;
-
usbi_mutex_lock(&ctx->flying_transfers_lock);
/* process the timeout that just happened */
int r;
struct usbi_pollfd *ipollfd;
POLL_NFDS_TYPE nfds = 0;
- struct pollfd *fds;
+ struct pollfd *fds = NULL;
int i = -1;
int timeout_ms;
nfds++;
/* TODO: malloc when number of fd's changes, not on every poll */
- fds = malloc(sizeof(*fds) * nfds);
+ if (nfds != 0)
+ fds = malloc(sizeof(*fds) * nfds);
if (!fds) {
usbi_mutex_unlock(&ctx->pollfds_lock);
return LIBUSB_ERROR_NO_MEM;
/** \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
return r;
}
- /* another thread is doing event handling. wait for pthread events that
+ /* another thread is doing event handling. wait for thread events that
* notify event completion. */
libusb_lock_event_waiters(ctx);
* held, see libusb_lock_events().
*
* This function is designed to be called under the situation where you have
- * taken the event lock and are calling poll()/select() directly on libusb's
+ * taken the event lock and are calling poll()/select() directly on libusbx's
* file descriptors (as opposed to using libusb_handle_events() or similar).
- * You detect events on libusb's descriptors, so you then call this function
+ * You detect events on libusbx's descriptors, so you then call this function
* with a zero timeout value (while still holding the event lock).
*
* \param ctx the context to operate on, or NULL for the default context
/** \ingroup poll
* Determines whether your application must apply special timing considerations
- * when monitoring libusb's file descriptors.
+ * when monitoring libusbx's file descriptors.
*
* This function is only useful for applications which retrieve and poll
- * libusb's file descriptors in their own main loop (\ref pollmain).
+ * libusbx's file descriptors in their own main loop (\ref pollmain).
*
- * Ordinarily, libusb's event handler needs to be called into at specific
+ * Ordinarily, libusbx's event handler needs to be called into at specific
* moments in time (in addition to times when there is activity on the file
* descriptor set). The usual approach is to use libusb_get_next_timeout()
* to learn about when the next timeout occurs, and to adjust your
* poll()/select() timeout accordingly so that you can make a call into the
* library at that time.
*
- * Some platforms supported by 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
* 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)
{
}
/** \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
+ * on libusbx'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.
*
*
* \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
*/
r = usbi_backend->clock_gettime(USBI_CLOCK_MONOTONIC, &cur_ts);
if (r < 0) {
usbi_err(ctx, "failed to read monotonic clock, errno=%d", errno);
- return LIBUSB_ERROR_OTHER;
+ return 0;
}
TIMESPEC_TO_TIMEVAL(&cur_tv, &cur_ts);
/** \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.
*
/** \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.
usbi_mutex_unlock(&ctx->pollfds_lock);
return (const struct libusb_pollfd **) ret;
#else
+ usbi_err(ctx, "external polling of libusbx's internal descriptors "\
+ "is not yet supported on Windows platforms");
return NULL;
#endif
}