1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
Building and Installing
-----------------------
See the "INSTALL" file.
Heritage
--------
libmtp is based on several ancestors:
* libptp2 by Mariusz Woloszyn was the starting point used
by Richard A. Low for the initial starter port. You can
find it at http://libptp.sourceforge.net/
* libgphoto2 by Mariusz Woloszyn and Marcus Meissner was
used at a later stage since it was (is) more actively
maintained. libmtp tracks the PTP implementation in
libgphoto2 and considers it an upstream project. We will
try to submit anything generally useful back to libgphoto2
and not make double efforts. In practice this means we
use ptp.c, ptp.h and ptp-pack.c verbatim from the libgphoto2
source code. If you need to change things in these files,
make sure it is so general that libgphoto2 will want to
merge it to their codebase too. You find libgphoto2 as part
of gPhoto: http://gphoto.sourceforge.net/
* libnjb was a project that Richard and Linus were working
on before libmtp. When Linus took Richards initial port
and made an generic C API he re-used the philosophy and
much code from libnjb. Many of the sample programs are for
example taken quite literally from libnjb. You find it here:
http://libnjb.sourceforge.net/
Compiling programs for libmtp
-----------------------------
libmtp has support for the pkg-config script by adding a libmtp.pc
entry in $(prefix)/lib/pkgconfig. To compile a libmtp program,
"just" write:
gcc -o foo `pkg-config --cflags --libs libmtp` foo.c
This also simplifies compilation using autoconf and pkg-config: just
write e.g.
PKG_CHECK_MODULES(MTP, libmtp)
AC_SUBST(MTP_CFLAGS)
AC_SUBST(MTP_LIBS)
To have libmtp LIBS and CFLAGS defined. Needless to say, this will
only work if you have pkgconfig installed on your system, but most
people have nowadays.
If your library is installed in e.g. /usr/local you may have to tell
this to pkgconfig by setting the PKG_CONFIG_PATH thus:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
Documentation
-------------
Read the API documentation that can be generated with doxygen.
It will be output in doc/html if you have Doxygen properly
installed. (It will not be created unless you have Doxygen!)
For information about the Media Transfer Protocol, see:
http://en.wikipedia.org/wiki/Media_Transfer_Protocol
Contributing
------------
See the project page at http://libmtp.sourceforge.net/
We always need your help. There is a mailinglist and a
bug report system there.
If you happen upon a device which libmtp claims it cannot
autodetect, please submit the vendor ID and device ID
as a bug, patch or feature request on the Sourceforge
bug tracker at our homepage. If it gives a sensible
output from "mtp-detect" then please attach the result as
well as it teach us some stuff about your device.
If your device is problematic we are curious of how it
works under Windows, so we enjoy reading USB packet sniffs
that reveal the low-level traffic carried out between
Windows Media Player and your device. This can be done
using the trial version of HHD Softwares software-only
USB monitor. You need to get a copy of version 2.37 since
the newer trial versions won't let you carry out the
needed packet sniffs. (As of 2007-03-10 a copy can be found
at: http://www.cobbleware.com/files/usb-monitor-237.exe)
There are other USB monitors as well, some more expensive
alternatives use hardware and even measure electronic
characteristics of the traffic (which is far too much
detail for us).
If you want to poke around to see if your device has some
special pecularities, you can test some special device
flags (defined in src/libusb-glue.h) by inserting them
together with your device entry in src/libusb-glue.c.
Flags can be tested in isolation or catenated with "|"
(binary OR). If relatives to your device use a certain
flag, chances are high that a new device will need it
too, typically from the same manufacturer.
Calendar and contact support:
-----------------------------
The Creative Zen series can read VCALENDAR2 (.ics) files
and VCard (.vcf) files from programs like for example
Evolution with the following limitations/conditions:
- The file must be in DOS (CR/LF) format, use the unix2dos
program to convert if needed
- Repeat events in calendar files do not seem to be supported,
entries will only appear once.
- Calendar (.ics) files should be stored in the folder "My Organizer"
when sent to the device (this directory should be autodetected
for use with calendar files, otherwise use the option
-f "My Organizer" to sendfile for this) Apparently this file can
also contain tasklists.
- Contact (.vcf) files should be stored in the folder "My Contacts"
when sent to the device. (-f "My Contacts")
- Some devices are picky about the name of the calendar and
contact files. For example the Zen Microphoto wants:
Calendar: My Organizer/6651416.ics
Contacts: My Organizer/6651416.vcf
Syncing in with Evolution and Creative Devices
----------------------------------------------
Evolution can easily export .ics an .vcf files, but you currently
need some command-line hacking to get you stuff copied over in
one direction host -> device. The examples/ directory contains a script
created for the Creative Zen Microphoto by Nicolas Tetreault.
It's Not Our Bug!
-----------------
Some MTP devices have strange pecularities. We try to work around
these whenever we can, sometimes we cannot work around it or we
cannot test your solution.
* The Zen Vision:M (possibly more Creative Zens) has a firmware bug
that makes it drop the last two characters off a playlist name.
It is fixed in later firmware.
* For Creative Technology devices, there are hard limits on how
many files can be put onto the device. For a 30 GiB device (like
the Zen Xtra) the limit is 6000, for a 60 GiB device the limit
is 15000 files. For further Creative pecularities, see the
FAQ sections at www.nomadness.net.
* Sandisk sansa c150 and probably several other Sandisk devices
(and possibly devices from other manufacturers) have a dual
mode with MTP and USB mass storage. The device will initially
claim to be mass storage so udev will capture is and make the
use of MTP mode impossible. One way of avoiding it could be to
be to blacklist the "usb-storage" module in
/etc/modprobe.c/blacklist with a row like this:
"blacklist usb-storage". Some have even removed the
"usb-storage.ko" (kernel module file) to avoid loading.
* The iriver devices (possibly all of them) cannot handle the
enhanced GetObjectPropList MTP command (0x9805) properly. So
they have been banned from using it.
* iriver devices have problems with older versions of libmtp and
with new devices libmtp does not know of as of yet, since it
has an oldstyle USB device controller that cannot handle zero
writes. (Register your device with us!) All their devices are
likely to need a special device flag in the src/libusb-glue.c
database.
* The Samsung Yepp T9 has several strange characteristics, some
that we've managed to work around. (For example it will return
multiple PTP packages in a single transaction.)
* The early firmware for Philips HDD players is known to be
problematic. Please upgrade to as new firmware as you can get.
(Yes this requires some kind of Windows Installation I think.)
* Very few devices that implement GetObjectPropList (0x9805) will
return the entire object list if you request a list for object
0xffffffffu. (But they should.) So we're currently not using
that feature.
|