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:
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.
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.
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.
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.)
The dc2xx driver supports up to sixteen devices, but most users won't need to use more than one or two cameras. If these device nodes aren't part of your distribution, make at least the first few of them as follows:
# 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
|
The mdc800 driver supports one device. If its device node isn't part of your distribution, make it as follows:
# 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.
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 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.
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.)
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