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