Библиотека сайта rus-linux.net
USB and Digital Still Cameras
While most digital still cameras support a serial line at up to 115 Kbps, the fastest ways to get pictures out of your camera onto Linux involve USB:
- USB Connection for Camera
Some cameras can connect directly to USB, normally using a custom jack on the camera, which is smaller than the standard type B jacks you see on the upstream side of hubs and other devices.
- USB Connection for Memory
A number of cameras don't have a direct USB hookup, but may come with an adapter that lets you connect their memory cards instead. Those cards are accessed using the mass storage driver, as if they were disk drives. (USB mass storage support is discussed elsewhere in this document.) You can buy such adapters separately; be sure that Linux supports the adapter model you want to use.
- PCMCIA Connection for Memory
Inexpensive PCMCIA adapters ($10US) let you treat memory cards like IDE disks. This won't be discussed any further here, but you should know the option exists. The transfer rate is higher than for USB, but the downside is that PCMCIA support is generally only available on laptops.
Only the first of these approaches is discussed in this section, where the camera has a direct connection to USB. The table below summarizes the most important information:
| Still Camera | Drivers | Applications | Notes |
|---|---|---|---|
| Kodak DC-240/280 | dc2xx | gPhoto | The first still cameras supported under Linux. USB lets you download pictures, take new ones, change camera settings, and more. |
| Kodak DC-220/260/265/290, HP PhotoSmart C-500 | dc2xx | ODS (no GUI) | DigitaOS runs these cameras, letting you run scripts on the camera as well as the sort of functionality available on the other DC-2xx series USB cameras. |
| Mustek MDC-800 | mdc800 | gPhoto | Only one camera at a time supported. |
| Sony DSC-505, Toshiba PDR-M4, and many USB card readers | storage, fat filesystem | ls, cp, mc, &c. | readonly for now |
Your kernel may already have the dc2xx, mdc800 and storage compiled as modules, or as part of the kernel. If it doesn't, rebuild so that you have them available.
Filesystem Device Nodes
If you use the dc2xx or mdc800 driver, you have all the security
hooks you need. The instructions shown below assume that PAM will be
set up to change ownership of these nodes to the logged-in user using
the /etc/console.perms file. If that is not done, think carefully about the ownership and permissions you use in the
instructions below. (Mode 0666 works for trusted systems, such
as single users workstations with no rlogin.)
# mknod -m 0660 /dev/usb/dc2xx0 c 180 80
# mknod -m 0660 /dev/usb/dc2xx1 c 180 81
# mknod -m 0660 /dev/usb/dc2xx2 c 180 82
# mknod -m 0660 /dev/usb/dc2xx3 c 180 83
...
# mknod -m 0660 /dev/usb/dc2xx15 c 180 95
|
# mknod -m 0660 /dev/usb/mdc800 c 180 32
|
If your connectivity uses the storage driver, see the section on that driver for more information.
Sanity Checking
After you think your kernel is set up, connect your camera to
your computer with USB (power it up!) and check to see if a kernel
message (perhaps in /var/log/messages)
reports the driver saw the
camera. If it didn't, you can do a bit of troubleshooting if you've
got "procfs" and the prototype "usbdevfs" code set up.
The first check is whether USB is basically set up. You
should see the driver listed in /proc/bus/usb/drivers;
if it's not there, use "modprobe" to load it. There should be a
bus directory such as /proc/bus/usb/001 also; if
there isn't, you may need to
"modprobe" the right host controller driver (OHCI or UHCI).
Then make sure that the kernel saw the camera. With it still
connected and powered up, check for an entry in
/proc/bus/usb/devices
corresponding to your camera. (The product ID string may name it.)
If there is no camera there, check your USB connections. If you
find the camera listed there, make sure it's one of the supported
cameras. There should be an "I: ..." line showing that driver. For
example, at the end of the line it would have "Driver=dc2xx",
"Driver=mdc800", or "Driver=storage". If you don't see that, then
the troubleshooting gets interesting.
gPhoto
gPhoto is a graphical application that knows how to talk to many different digital cameras. At this writing its current version (0.4.3) knows how to use USB to talk to three cameras: appropriate camera model and use an "other" (non-TTY) device path name as shown above. (Use dc2xx0 unless you have multiple cameras.) Check the "Camera Summary" to see if it's connected properly.
At that point, you should be able to download thumbnails of all the pictures in the camera, then download the pictures you've chosen. (At this writing, it's visibly faster to use OHCI than to use UHCI.)
More information about gPhoto is available at its web site, www.gPhoto.org.
DigitaOS Cameras and ODS
At this writing, gPhoto does not know how to communicate with cameras using the "DigitaOS" environment. However, there is a separate "Open Digita Services" project which can be used to do that. See that project's web site, at ods.sourceforge.net.
(There are also various Perl and Python scripts available to provide some of this functionality, if you prefer to develop in those languages rather than in C.)
Other Approaches (Developers only)
The solutions described above are, at this writing, the most widely used ones. You may be interested to know about some other solutions that might work.
You can configure the usbserial
module with "generic serial" driver support. This lets you
provide kernel module parameters that let the serial driver
handle specific bulk-only devices (using USB product and
vendor IDs). The Kodak or ODS cameras mentioned above are
bulk-only, so this might permit /dev/usb/ttyN
style paths to work instead of /dev/usb/dc2xxN
style ones.
Systems which enable the "prototype usbdevfs" support
can configure it to allow appropriately intelligent user
mode programs to access USB devices. This requires libraries
that know how to interact with /proc/bus/usb/NNN/MMM
files for each USB device, ways to address security issues that
arise (programs need read/write access), and ways to have
user and kernel mode software interact safely. Such work
is under way. See for example the Java USB project at
jusb.sourceforge.net
and the C "libusb" at libusb.sourceforge.net