Move the libmtp source from jumper to external.
Change-Id: I06bce6628cf809af6f7125c8fb4115bafd7c6c87
diff --git a/TODO b/TODO
new file mode 100644
index 0000000..74ad560
--- /dev/null
+++ b/TODO
@@ -0,0 +1,106 @@
+TODO file:
+----------
+
+COMPATIBILITY fixes:
+
+1. COMPATIBILITY: dual-mode devices, i.e. devices exposing both an MTP
+ and a USB Mass Storage Device Class (flashdrive) interface are and
+ have always been problematic. We must find a way to get this to work,
+ eventually. The problem is that the in-kernel mass storage driver hogs
+ the device before the MTP mode gets a chance of being used, whereas
+ the Windows kernel driver apparently does it the other way around,
+ trying the MTP mode first and then not fall back on mass storage if
+ MTP is available. (For some more explanations se src/libusb-glue.h.)
+ This may involve kernel modifications. Perhaps it is only necessary
+ to tweak the udev config not to load USB mass storage support for
+ these devices. Dunno.
+
+2. COMPATIBILITY: several devices tend to "hang" after disconnect,
+ needing to be unplugged and replugged before they can be used again.
+ We don't know why, it may be related to low-level USB behaviour that
+ is not exposed in the logs we read. On some devices it appear that
+ avoiding to release the USB interface after closing the PTP/MTP
+ session solves this, and might be a hint at how the Windows MTP stack
+ works: perhaps the Windows MTP daemon grabs the interface once the
+ device is plugged in, created a session and NEVER release it.
+ Thus only unplug or shutdown ends the session. This behaviour can be
+ emulated (sort of) by DEVICE_FLAG_NO_RELEASE_INTERFACE which will
+ make the device not release the USB low-level interface, though it'll
+ still close the session. But is it really desireable to have
+ as default? Not unless we run an MTP daemon as well, probably, and
+ the behaviour is questionable from an USB interoperability point
+ of view.
+
+
+SPEEDUP fixes:
+
+ None known. libmtp is fast :-)
+
+
+FEATURE fixes:
+
+1. FEATURE: Support playback and volume setting on devices that have it.
+ (I don't have one that does - Linus.)
+
+2. FEATURE: Support relevant events. MTP devices seen in existance provide
+ events for "object added" and "object deleted". These should result in
+ atleast a call to the cache update function.
+
+3. FEATURE: Mechanism to retrieve the device icon device property, else if not
+ present, look for DevIcon.fil (Windows ICO format) and
+ DevLogo.fil (PNG Format) images from the device (if available).
+
+4. FEATURE: Shared device access so that multiple client applications can have
+ an open connection to the device at the same time via a handle. For example,
+ it should be somehow possible to run mtp-detect at the same time as amarok or
+ mtpfs is connected to a device. This would require some form of resource
+ sharing.
+
+5. FEATURE: Implement an OpenSync backend for devices which have
+ calendaring, contact etc support. http://opensync.org/
+
+
+THOSE ARE ALREADY DONE:
+
+1. FEATURE: Make an API that can return several devices and let the user
+ choose which one to operate, not just connect to the first one...
+
+2. SPEED: Cache the object info for all items on the device.
+ Right now, ptp_getobjectinfo() is called repeatedly on the same
+ objects during startup, track listing, file listing, playlist listing,
+ album listing and whatever we implement tomorrow. A lot of useless
+ communication can be saved by cacheing this info. Notice that this
+ needs to be updated whenever flush_handles() is called too.
+ (This came from libgphoto2 implementing it!)
+
+3. SPEED: Cache track metadata, file metadata etc in params->proplist.
+
+4. SPEED: Whenever we add an object (file, track, playlist...) we
+ should only need to update the cache with relevant data. Atleast for
+ speedup caches.
+
+5. COMPATIBILITY: account for different step sizes and intervals on some
+ numeric properties we set, make the functions round off when possible.
+
+6. SPEED: Cache the supported object properties at first read/startup.
+ then use the cache to check for supported props instead of calling
+ out to PTP with ptp_mtp_getobjectpropssupported() every time.
+ The cache would be an array of size params->deviceinfo.ImageFormats_len
+ with a list for each format of the properties it will support. Notice
+ that this needs to be updated whenever flush_handles() is called too.
+ THIS HAS BEEN DISCARDED, TERO IMPLEMENTED IT BUT IT DOESN'T SEEM TO
+ YIELD MUCH.
+
+7. FEATURE: Make abstract playlists really become size -1 when created as
+ the ones created on the device instead of the current 1 byte size.
+ (Is this possible using enhanced commands? See TODO remarks in
+ the create_abstract_entity() function)
+
+8. FEATURE: Integrate libmtp with HAL / D-Bus so applications can dynamically
+ know when a device has been plugged in or removed. Need a mechanism to
+ connect a specific hal UDI.
+
+9. SPEEDUP: The recursive function that builds the folder tree is
+ O(n^2)! Atleast remove all non-folders (PTP associations) from the
+ list before we start sorting and building that tree. We walk the
+ entire list for each group of siblings right now!