Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
main interesting thing:
- size / overflow checking for various usb data unpacker functions
- small api changes
adapted callers in libusb*glue.c and libmtp.c
|
|
|
|
|
|
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.
|
|
54643 Uninitialized scalar variable
|
|
54604 Logically dead code
|
|
54645 Dereference before null check
|
|
initialize the global usb1 context only once to avoid memory leaks.
|
|
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>
|
|
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
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>
|
|
Signed-off-by: Yingxi Yu <yingxi.yu@intel.com>
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
This reverts commit 77ad0b15fecacb415dc508168919cc3c4583dd36.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Lei Zhang <thestig@google.com>
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
Signed-off-by: Lei Zhang <thestig@google.com>
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
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>
|
|
|
|
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
Signed-off-by: Jonas Salling <jonas@salling.com>
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
Signed-off-by: Linus Walleij <triad@df.lth.se>
|
|
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>
|
|
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>
|
|
This reverts commit c9105ab04321f5dce1f15cd5d152d2d63820cd2d.
Conflicts:
configure.ac
|
|
Signed-off-by: Marcus Meissner <marcus@jet.franken.de>
|