mounting my camera as a normal (usb) device

Wed Nov 14 19:26:41 GMT 2012

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.