diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 113 |
1 files changed, 113 insertions, 0 deletions
@@ -0,0 +1,113 @@ +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, discussions have centered on a D-Bus based connection arbiter + daemon. + +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! + +10. FEATURE: program to autoprobe device interfaces on connection. + +11. FEATURE: accomodate Googles uncached device needs. + +12. FEATURE: rudimentary event interface. |