diff options
author | Pete Batard <pete@akeo.ie> | 2012-04-03 13:40:39 +0100 |
---|---|---|
committer | Pete Batard <pete@akeo.ie> | 2012-04-03 15:42:10 +0100 |
commit | 791b7473ec38155ee3d1d9889f3d0f1b4c8f33f0 (patch) | |
tree | 009cb8fb6347691d69125939a399d538a21cca02 /libusb/io.c | |
parent | f98eaca0985364be00fcfde3fd3884075092a4e9 (diff) | |
download | android_external_libusbx-791b7473ec38155ee3d1d9889f3d0f1b4c8f33f0.tar.gz android_external_libusbx-791b7473ec38155ee3d1d9889f3d0f1b4c8f33f0.tar.bz2 android_external_libusbx-791b7473ec38155ee3d1d9889f3d0f1b4c8f33f0.zip |
Misc: Rebrand to libusbx
* Mentions of 'libusb' in doxygen are changed to 'libusbx'
* Also update copyright notices and remove unneeded EOF LFs
Diffstat (limited to 'libusb/io.c')
-rw-r--r-- | libusb/io.c | 184 |
1 files changed, 92 insertions, 92 deletions
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. |