Re: mounting my camera as a normal (usb) device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Duncan,


Thank you *very* much for your very clear explanation of how this all works. I haven't digested everything yet, nor resolved the issue yet, but you have given several clues that I need to follow-up. One thing, also as a reply to chuck's mail: in the dmesh there is no mentioning of any sdaX device.
To be precise, this is what appears in  /var/log/messages:

====
Nov 14 20:22:37 beethoven kernel: usb 2-4: new high speed USB device number 4 using ehci_hcd Nov 14 20:22:37 beethoven kernel: hub 2-0:1.0: unable to enumerate USB device on port 4 Nov 14 20:22:38 beethoven kernel: usb 2-4: new high speed USB device number 5 using ehci_hcd Nov 14 20:22:38 beethoven kernel: usb 2-4: New USB device found, idVendor=04b0, idProduct=042a Nov 14 20:22:38 beethoven kernel: usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 14 20:22:38 beethoven kernel: usb 2-4: Product: NIKON DSC D800
Nov 14 20:22:38 beethoven kernel: usb 2-4: Manufacturer: NIKON
Nov 14 20:22:38 beethoven kernel: usb 2-4: SerialNumber: 000006067163
Nov 14 20:23:42 beethoven dbus-daemon[1081]: **** /proc/self/mountinfo changed
=====

Regards,
Bertwim


On 11/13/2012 09:14 PM, Duncan wrote:
B.W.H. van Beest posted on Mon, 12 Nov 2012 23:14:17 +0100 as excerpted:

When I connect my camera to my computer (opensuse 12.2, kde 4.8.5) I can
mount it via the device notifier, selecting the option "open in
filemanager".
Then konqueror pops up and opens a screen using the "camera:" protocol.

Although this may look nice, it isn't!   It turns out to be very slow,
error prone and unreliable.
I prefer to mount the camera "the old way", that is, just as an ordinary
usb -device so that I can in a konsole copy the files from the camera to
a destination directory.
But I have no clue how that should be done. Can somebody give me a hint
or clue?
Let me put this right at the top.  I don't personally have such a camera
or other device (cell phones are common, media players...), so I'll be
limited in the amount of specifics I can give you.  However, I have some
knowledge of the general technology and how Linux (and kde) deals with
that, that I can share, that will hopefully at least point you in the
right direction.

In general there are at least three standard or semi-standard methods for
accessing and transferring files to/from a USB device.  Two of these, PTP
(picture transfer protocol, for cameras) and MTP (media transfer
protocol, for portable media players) are related and compatible, tho
aimed at different devices.  The third, USB MSC (USB mass storage device
class), aka UMS (USB mass storage), is much different, more general
purpose (tho USB specific), and faster, but has one significant
limitation that the other two avoid.

For more about each than I care to write, check the wikipedia entries:

http://en.wikipedia.org/wiki/Picture_Transfer_Protocol

http://en.wikipedia.org/wiki/Media_Transfer_Protocol

http://en.wikipedia.org/wiki/USB_mass_storage_device_class

MTP is an originally Microsoft extension of PTP designed to support DRM
(digitial restrictions management), etc, on portable media players.  It
was standardized in 2008.  PTP was designed as a common object transfer
protocol by the various digital camera manufacturers.  Both variants
operate on individual objects (generally files) as provided by the USB
gadget (as opposed to host, generally computer) device.  The operating
system on the USB device remains in full control of how it actually
manages these objects and over what it exposes or choses not to expose.
As such, it's ideally suited to various DRM schemes, since the OS can
simply refuse to deal with (expose, outgoing, save, incoming) anything
that doesn't have the appropriate DRM tags.

On Linux, PTP/MTP access is provided to an implementing app by user-space
libraries, so only specific applications which choose to support it (and
thus depend on those libraries) can be used.  Apps that haven't built in
that support simply won't see PTP/MTP at all.

Meanwhile, of specific interest in this thread, since MTP/PTP access is
mediated by the devices OS, (1) it's possible (indeed, required) to
access objects while the device is "on" without risk of corruption or
damage to the underlying filesystem, and (2) speeds are often limited by
the relatively high level access provided due to the additional
processing required on the often relatively slow device CPU.

This (PTP in this case) would appear to be the access method exposed by
the camera:// protocol, while the alternative USB mass storage would
appear to be what you're after.


USB mass storage (UMS) by contrast, is a much lower level access
protocol.  It presents something very close to a raw block device, which
the accessing USB host (computer) is able to manipulate pretty much as it
will.  This tends to be much faster since the gadget's normally
relatively slow (as compared to the host computer) CPU does much less
processing, pretty much just exposing the underlying storage device as-
is.  HOWEVER, because it allows the accessing host virtually unlimited
access, it's not safe to allow both the gadget's normal access and the
hosts direct access at the same time, so the USB gadget device must be
"off" in terms of its normal OS while in UMS mode.  This can be quite
inconvenient for phones especially, but also prevents UMS mode access and
listening to a media player over its headphones at the same time, for
instance.  Thus, UMS mode, while faster and less restricted, is becoming
less popular as portable devices merge and such devices are more often a
phone/tablet/media-player/camera all-in-one, where you often do NOT want
to shut off the device and thus stop taking calls, etc, just to put it in
exclusive-access UMS mode.

But as your device is apparently a dedicated camera, this shouldn't be
such an issue, and UMS mode should be quite practical... assuming your
device supports it of course, which it probably does. =:^)

Because the underlying block device is exposed to the host OS /as/ a
normal block device, it's of course possible to format it as one would
any other block device.  So in theory you could fdisk it and format
various partitions as ext4, fat32, etc.  The problem is that the embedded
OS probably understands only fat32 or the like, and may not even
understand partitions, so while you /could/ do that, it could well brick
the device in terms of its original purpose, such that it's now only a
fancy and expensive USB stick with some extra but worthless additional
hardware.  That's obviously not something most users would want, but it's
precisely the flexibility of the low-level block-device access that UMS
mode exposes, that allows you do do it anyway, should you decide to do so.

On Linux, a kernel module provides the UMS "driver".  With it (and
associated SCSI modules, etc) loaded and the device attached in UMS mode,
the device appears as an ordinary block device, typically as /dev/sdX
(where X is a letter).

Depending on your automount configuration, the device may be automounted,
typically as /media/something-or-other.  Alternatively, on kde it'll show
up in the device notifier and you can mount it and open in konqueror, etc.

Alternatively, as Chuck suggested, you can use the standard commandline
mount/umount tools, and/or setup an entry for it in fstab, as you would
any other block device with a filesystem on it.


The key I suspect you're missing, however, is that UMS is an entirely
separate access mode on the USB gadget device (your camera in this
case).  Some such devices have a method to select which mode they appear
in.  Others automatically present ptp/mtp mode if connected while they're
"on", or in UMS mode if they're connected while they're "off".  Either
way, in ordered to get UMS mode, you must figure out how your device
exposes it (manual mode switch or simply on/off toggle), or indeed,
whether it exposes UMS mode at all (some devices don't), and activate
that on the device, before it's connected.

Once you connect the device in UMS mode, kde's device notifier should
detect it, and "open using konqueror" should "just work" as it would with
any other USB mass storage device, thumb drive, portable disk, etc.
Alternatively, you can use the standard Linux block device and filesystem
tools, fdisk, mkfs, fsck, mount/umount, an entry in /etc/fstab, etc.


___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux