aboutsummaryrefslogtreecommitdiff
path: root/src/libusb1-glue.c
AgeCommit message (Collapse)Author
2016-07-01fix indentation for gcc6Marcus Meissner
2016-04-14[events] Add an asynchronous function to check for eventsPhilip Langdale
The existing LIBMTP_Read_Event function blocks while waiting for an event. This can lead to race conditions where a client attempts to disconnect from the device in one thread while an event just happens to arrive in the polling thread, with unpredictable results, including attempts to disconnect twice. To make life easier for clients, we can offer an asynchronous form of event checking, which gives the client the ability to terminate polling when necessary. To do this, we can leverage the asynchronous capabilities of libusb-1. That's only one of three possible backends, but it's the most commonly and heavily used library. Starting an asynchronous transfer is pretty straightforward, but polling can be done in a variety of ways, some of which are very complicated. For my purposes, one of the simpler forms is sufficient, and, in fact, the most generalised form doesn't offer me any advantages. Accordingly, I put a trivial wrapper around this method so that it can be used without making the client explicitly pull in libusb-1. It's a bit weird, but worth the convenience. So, we now have a Read_Events_Async that takes a callback and a Handle_Events method that will poll for activity. How have we solved the original problem? There are two ways. 1) We can pass a timeout to Handle_Events. This will cause it to return if no activity happened. We can then assess whether it is safe to poll some more or give up. 2) libusb has recently added an 'interrupt_event_handler' function https://github.com/libusb/libusb/commit/a6db382ad11f7662b550338e0570d5a2dfd8ce5a This function finally offers a way to interrupt polling on demand. No release of libusb with this in it has happened yet, but hopefully it will happen soon. Now, you could ask, with fairness, why this interrupt mechanism shouldn't work with the existing synchronous Read_Event; and I agree - it should - but it doesn't. Due to a bug in libusb, even though the interruption works, the synchronous wrapper code they have will immediately start the polling again and never return control to the caller. So, even when we're in a position to use this interruption function, we'll still need to be using the async API to take advantage of it. I've verified that all this logic works in gvfs.
2016-02-21merge accumulated ptp lowlevel changes from libgphoto2.Marcus Meissner
main interesting thing: - size / overflow checking for various usb data unpacker functions - small api changes adapted callers in libusb*glue.c and libmtp.c
2016-02-05in read, use the maxpacket from the device, not _HS_ packetsizeMarcus Meissner
2015-10-04memory leaks on error exits (Coverity)Marcus Meissner
2015-06-17util: wrap unknown-device erroring in just one functionAndrés G. Aragoneses
The way to error out about an unknown device was being triplicated in the code. This commit shouldn't bring any behaviour change, as it's just refactoring.
2015-04-09initialize xwritten for rare bugs (Coverity)Marcus Meissner
54643 Uninitialized scalar variable
2015-04-09remove double if () (Coverity)Marcus Meissner
54604 Logically dead code
2015-04-09avoid using params before checking it against NULL (Coverity)Marcus Meissner
54645 Dereference before null check
2015-04-01https://sourceforge.net/p/libmtp/patches/64/Marcus Meissner
initialize the global usb1 context only once to avoid memory leaks.
2014-08-24Revert "Async buffering for high-speed transfers."David Bremner
This reverts commit b9a840cc79bb96f135fe4abd4248881240026112. Conflicts: src/libusb-glue.h The only non-obvious conflict is because of later changes to how libusb.h is included Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-11-06minor coding style cleanupLinus Walleij
Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-11-06delete unused clear_halt()codeLinus Walleij
Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-11-06Async buffering for high-speed transfers.Yingxi Yu
This adds an asynchronous buffering mechanism for pumping high-speed transfers when using libusb1. Signed-off-by: Yingxi Yu <yingxi.yu@intel.com> Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-11-06USB3 device supportYingxi Yu
Signed-off-by: Yingxi Yu <yingxi.yu@intel.com> Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-11-06Revert "USB 3.0 support."Linus Walleij
This reverts commit 77ad0b15fecacb415dc508168919cc3c4583dd36.
2013-11-04USB 3.0 support.Yingxi Yu
This adds support for USB 3.0 capable MTP devices. Signed-off-by: Yingxi Yu <yingxi.yu@intel.com> Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-05-01PATCH: avoid unconditional clear_haltMarcus Meissner
Hi, During debugging weird "access only possible once" scenarios, on Raspberry Pi and also on regular Linux with USB 3.0 controllers, I found that clearing halt on a endpoint which is not stalled will confuse the (kernel) driver and device and make them really stall until resetted. This is probably a Kernel bug. So do not do a unconditional clear_halt. I am leaving the conditional clear_stall in, as it queries the status before. This might need testing. Ciao, Marcus Signed-off-by: Marcus Meissner <marcus@jet.franken.de> Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-04-18Support GetObject for large (>4GB) files.Philip Langdale
In general, GetObject for large files is much like SendObject; you keep trying to transfer data until the sender stops. The existing code does almost everything you need, except it doesn't use a sufficient condition to detect the case. While you might think that a large transfer would be signaled with a containerLength of 0xFFFFFFFF - this has not proven the case in my testing; what I see is the file size truncated to 32bits. This makes the existing condition ineffectual. An alternative condition, suggested by Han-Wen, is to simply always use the sender-limited transfer pattern if the transfer is larger than one packet. This means that the containerLength is ignored for any transfer over 512 bytes, but it works, and it's really the only way to handle the corner case where the large file size truncates to a small value < 512. Signed-off-by: Philip Langdale <philipl@overt.org> Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-04-09ptp: Apply missing changes to support > 4GB transfers.Philip Langdale
Not sure why, but these changes were dropped when the original patchset was applied. The rest of the changes to ptp made it in. Signed-off-by: Philip Langdale <philipl@overt.org> Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-03-12Fix some leaks in common code paths.Lei Zhang
Signed-off-by: Lei Zhang <thestig@google.com> Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-03-12Check for failures from libusb_init() in the libusb-1.0 glue code.Lei Zhang
Signed-off-by: Lei Zhang <thestig@google.com> Signed-off-by: Linus Walleij <triad@df.lth.se>
2013-03-05Fix signature of ptp_usb_senddata() to be 64bit.Linus Walleij
Signed-off-by: Linus Walleij <triad@df.lth.se>
2012-11-13Patch from Will Preston to fix setup of descriptor.Linus Walleij
Signed-off-by: Linus Walleij <triad@df.lth.se>
2012-11-13Close dangling handle in libusb glueLinus Walleij
Signed-off-by: Linus Walleij <triad@df.lth.se>
2012-08-20Do not always set altinterface 0! This is just wildly wrong:Linus Walleij
if we need ever do that it must be where we can detect that it needs changing, so #if 0 it for now. Also added code to change config if the desired one is not already active. Signed-off-by: Linus Walleij <triad@df.lth.se>
2012-03-22This is not older libusb...Linus Walleij
2012-01-28Just docsLinus Walleij
Signed-off-by: Linus Walleij <triad@df.lth.se>
2012-01-21Fixed one syntax error, straightened a few spacesLinus Walleij
Signed-off-by: Linus Walleij <triad@df.lth.se>
2012-01-20There was some unfinished porting here.Jonas Salling
Signed-off-by: Jonas Salling <jonas@salling.com> Signed-off-by: Linus Walleij <triad@df.lth.se>
2012-01-18VariousLinus Walleij
Signed-off-by: Linus Walleij <triad@df.lth.se>
2011-11-17Clean up separation between libusb 1.0 and libusb 0.xLinus Walleij
Some symbols from <usb.h> were still used here and there in the libusb glue code. Remove <usb.h> from the libmtp.h header, what did it do there in the first place? Signed-off-by: Linus Walleij <triad@df.lth.se>
2011-11-17Make libusb 1.0 and libusb 0.x coexist, merge Marcus' libusb 1.0Linus Walleij
support. This makes autoconf select between libusb 1.0 and libusb 0.x at configure-time, use a common libusb-glue.h for both but split implementation files: libusb1-glue.c is the new one for libusb 1.0 and libusb-glue.c is the old one, which will hopefully be phased out one day. Signed-off-by: Linus Walleij <triad@df.lth.se>
2011-11-16Revert "Rewrite libmtp to use libusb1, drop legacy libusb support."Linus Walleij
This reverts commit c9105ab04321f5dce1f15cd5d152d2d63820cd2d. Conflicts: configure.ac
2011-11-14Rewrite libmtp to use libusb1, drop legacy libusb support.Linus Walleij
Signed-off-by: Marcus Meissner <marcus@jet.franken.de>