The USB device filesystem is a dynamically generated filesystem, similar to the /proc filesystem. This filesystem can be mounted just about anywhere, however it is customarily mounted on /proc/bus/usb, which is an entry node created by the USB code, intended to be used as a mount point for this system. Mounting in other locations may break user space utilities, but should not affect the kernel support. You need to select "Preliminary USB Device Filesystem" to make this work. You also need to enable general /proc support, and to have it mounted (normally automatic). To mount the filesystem, you need to be root. Use the mount command: mount -t usbdevfs none /proc/bus/usb. Note that the none keyword is arbitrary - you can use anything, and some people prefer to use usbdevfs , as it makes the mount output look better. If you do not want to have to mount the filesystem each time you reboot the system, you can add the following to /etc/fstab after the /proc entry: none /proc/bus/usb usbdevfs defaults 0 0 This has the same effect as the mount command. After you have mounted the filesystem, the contents of /proc/bus/usb should look something like: dr-xr-xr-x 1 root root 0 Jan 26 10:40 001 -r--r--r-- 1 root root 0 Jan 26 10:40 devices -r--r--r-- 1 root root 0 Jan 26 10:40 drivers . You may have more than one numbered directory entry if your machine has more than one universal serial bus controller. Full interpretation of the devices and drivers files is provided later in this guide, in the user's section. The numbered entries are machine readable, but are not usually of any use to a user. There are two options for using a USB mouse or a USB keyboard - the standalone Boot Protocol (HIDBP) way and the full featured HID driver way. The Boot Protocol way is generally inferior, and this document describes the full featured way. The Boot Protocol way may be appropriate for embedded systems and other systems with resource constraints and no real need for the full keyboard and mouse capabilities. It is important to remember that the HID driver handles those devices (or actually those interfaces on each device) that claim to comply with the Human Interface Device (HID) specification. However the HID specification doesn't say anything about what the HID driver should do with information received from a HID device, or where the information that is sent to a device comes from, since this is obviously dependent on what the device is supposed to be doing, and what the operating system is. Linux (at the operating system kernel level) supports four interfaces to a HID device - keyboard, mouse, joystick and a generic interface, known as the event interface. These are implemented by the Input device level. In the kernel configuration stage, you need to turn on USB Human Interface Device (HID) support in the USB support and Mouse Support in the Input core support. You don't need to worry about the screen resolution entries for a normal mouse - these are for mouse-like devices such as a graphics tablet. Do not turn on USB HIDBP Mouse support. Perform the normal kernel rebuild and installation steps. If you are installing as modules, you need to load the input.o, hid.o and mousedev.o modules. Plug in a USB mouse and check that your mouse has been correctly sensed by the kernel. If you don't have a kernel message, look for the changes to /proc/bus/usb/devices. Since USB supports multiple identical devices, you can have multiple mice plugged in. You can get each mouse seperately, or you can get them all mixed together. You almost always want the mixed version, and that is what will be used in this example. You need to set up a device node entry for the mixed mice. It is customary to create the entries for this device in the /dev/input/ directory. Use the following commands: mkdir /dev/input mknod /dev/input/mice c 13 63 If you cat /dev/input/mice you should see some bizarre looking characters as you move the mouse or click any of the buttons. If you want to use the mouse under X, you have various options. Which one you select is dependent on what version of XFree86 you are using and whether you are using only USB for your mouse (or mice), or whether you want to use a USB mouse and some other kind of pointer device. You need to edit the XF86Config file (usually /usr/X11R6/lib/X11/XF86Config or /etc/X11/XF86Config). If you are using XFree86 version 4.0 or later, add a InputDevice section that looks like the following: Section "InputDevice" Identifier "USB Mice" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mice" EndSection or, if you want to use a wheel mouse, something like: Section "InputDevice" Identifier "USB Mice" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5" Option "Buttons" "5" EndSection may be more useful. Consult the XFree86 documentation for a detailed explaination and more examples. You also need to add an entry to each applicable ServerLayout Section. These are normally at the end of the configuration file. If you only have a USB mouse (or USB mice), then replace the line with the "CorePointer" entry with the following line: InputDevice "USB Mice" "CorePointer" If you want to use both a USB mouse (or USB mice) and some other kind of pointer device, then add (do not replace) the following line to the applicable ServerLayout sections: InputDevice "USB Mice" "SendCoreEvents" If you are using only a USB mouse (or USB mice) with XFree86 3.3, edit the Pointer section so that it looks like the following: Section "Pointer" Protocol "IMPS/2" Device "/dev/input/mice" EndSection If you are trying to use a USB mouse (or USB mice) in addition to another pointer type device with XFree86 3.3, then you need to use the XInput extensions. Keep the existing Pointer (or modify it as required for the other device if you are doing an initial installation), and add the following entry (anywhere sensible, ideally in the Input devices area): Section "Xinput" SubSection "Mouse" DeviceName "USB Mice" Protocol "IMPS/2" Port "/dev/input/mice" AlwaysCore EndSubSection EndSection Restart the X server. If you don't have any mouse support at this point, remember that Ctrl-Alt-F1 will get you a virtual terminal that you can use to kill the xserver and start debugging from the error messages. If you want to use the mouse under gpm, run (or kill and restart if it is already running) gpm with the following options. gpm -m /dev/input/mice -t imps2 (as superuser remember). You can make this the default if you edit the initialisation files. These are typically named something like rc.d and are in /etc/rc.d/ on RedHat distributions. If you have both a USB mouse (or USB mice) and some other kind of pointer device, you may wish to use gpm in repeater mode. If you have a PS/2 mouse on /dev/psaux and a USB mouse (or USB mice) on /dev/input/mice, then the following gpm command would probably be appropriate: gpm -m /dev/input/mice -t imps2 -M -m /dev/psaux -t ps2 -R imps2. Note that this will make the output appear on /dev/gpmdata, which is a FIFO and does not need to be created in advance. You can use this as the mouse "device" to non-X programs, and both mice will work together. The USB Scanner driver is capable of supporting just about any scanner. However meaningful output depends on the availability of a suitable user space tool, such as SANE, see http://www.mostang.com/sane. If your scanner is not automatically associated with the scanner driver, you have two options. The first option is to edit the source code for the scanner driver - I assume that if you can do this, you won't need any instructions. The second option is to use modules, and to load the module with the vendor and product IDs specified as module options: insmod scanner.o vendor=0xXXXX product=0xYYYY, where XXXX is the hexadecimal vendor ID code, and YYYY is the hexadecimal product ID code, which you can extract from the contents of /proc/bus/usb/devices when you have the scanner plugged in. You need to create an appropriate device file entry, using commands (as root) like the following: mknod /dev/usb/scanner0 c 180 48 chmod a+rw /dev/usb/scanner0 To use the scanner device, you will need a suitable tool. SANE is strongly recommended. If you don't already have it installed or your installation is old, you will need to retrieve the package from the closest of the sites referenced at http://www.mostang.com/sane/source.html. For instructions on building and installing SANE, refer to the various README files within the SANE distribution, and more detailed instructions for specific scanners that are provided later in this document. The Microtek scanner driver presents the scanner as a generic SCSI device, which is probably /dev/sg0 unless you have some other device that uses the SCSI generic device interface. In addition to selecting the Microtek X6USB scanner support entry in USB support, you also need to select SCSI generic support under SCSI support. You need a very recent SANE release (1.0.3) or later to use this driver. If you don't already have it installed or your installation is old, you will need to retrieve the package from the closest of the sites referenced at http://www.mostang.com/sane/source.html. For instructions on building and installing SANE, refer to the various README files within the SANE distribution, and more detailed instructions for specific scanners that are provided later in this document. 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. 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 To be done. See http://rio500.sourceforge.net The D-Link USB FM radio driver uses the Video4Linux interface, similar to the webcams discussed above. If the appropriate device node entries do not exist, you should create them: mknod /dev/video0 c 81 0 mknod /dev/video1 c 81 1 mknod /dev/video2 c 81 2 mknod /dev/video3 c 81 3 ln -s /dev/video0 /dev/video After plugging the radio in, all you should you need to do is to start up an appropriate application - I normally use kradio and KTuner from KDE, although any Video4Linux radio application should work successfully.