Configure USB devices to Linux: task 2.4
Configuring USB devices to a Linux system important because most accessories now interface through computers with them. Learn more here.
Task 2.4: Configure USB Devices
USB 1.0, the first incarnation of USB, was finalized in 1996. Since then, USB has played an increasingly important role. Today, mice, printers, scanners, digital cameras, CD-RW drives, and many other devices can interface to computers via USB. Thus, being able to configure USB devices to work with Linux is an important skill.
USB was designed to permit relatively painless hot-plug operation, meaning that devices can be plugged into the computer and unplugged while the computer operates. Unfortunately, this type of operation is alien to Linux's basic driver model. Thus, to accommodate USB's hot-plug nature, various special utilities and interfaces have been developed. Configuring USB devices means working with these utilities.
Scenario
To support efforts to digitize old documents and presentations, your employer has purchased a film scanner. This scanner uses a USB interface and must be configured to work correctly with Linux; however, your default Linux configuration prevents ordinary users from accessing the scanner when it's plugged into the computer and turned on. You must reconfigure Linux to enable ordinary users to work with the scanner.
Scope of Task
This task involves examining configuration and system status files to learn about your hardware and then modifying configuration files to have the system configure hardware in the way you want. If you're lucky, you won't need to engage in the low-level configuration described here; many distributions provide tools that automatically detect and configure a wide variety of USB devices. These tools fail with obscure or very new hardware, though, necessitating manual configuration.
Duration
This task will take about half an hour to complete. Once you're familiar with the procedure, you should—in theory—be able to perform similar tasks in half that time. In practice, though, adding hardware often involves overcoming unexpected problems. Thus, when you add your own truly unknown hardware, you could end up taking anywhere from a few minutes to several hours to configure it.
Setup
To complete this task, you need root access to a Linux computer. Ideally, you should have a scanner or other USB device that's not accessible to ordinary users in your default configuration. (For this task, I use a Minolta DiMAGE Scan Elite 5400 film scanner and Fedora Core 5 as the example hardware and software.) This example assumes that your system uses the udev filesystem for handling device files, which is common with modern distributions. If you lack appropriate hardware or software, you should still be able to follow along and examine the relevant configuration files on your computer.
Your Linux computer should be booted and your USB device should be ready to be connected to the computer. Although some steps can be completed as an ordinary user, and some testing must be completed as an ordinary user, you will have to complete some steps as root.
Caveats
Modifying the hardware configuration is inherently risky. An error in modifying configuration files could render a wide variety of devices useless. Thus, you should be very cautious when performing this task, above and beyond the usual caution when performing actions as root. Back up any file you plan to change so that you can restore it via an emergency boot system if necessary.
Procedure
Adding USB hardware involves two basic steps: identifying the hardware and modifying configuration files that tell Linux how to add device files for the hardware. The first step requires examining USB information files, and the second involves modifying udevconfiguration files.
Identifying USB Hardware
Before identifying your USB hardware, be sure that the device you want to identify is plugged in and (if applicable) turned on. You can then view the contents of the /proc/bus/usb/devicespseudo-file, say by using less. You'll see several entries for your USB controller hardware on your motherboard or add-on USB cards, as well as entries for USB mice, printers, and other devices. To find the entry for your device, look for the manufacturer's or product's name on the Manufactureror Product lines. The entry for the Minolta DiMAGE Scan Elite 5400 looks like this:
Most of this information isn't particularly important for configuring the hardware; however, some information is important, either for configuration or for possible troubleshooting:
Bus number The Bus item on the first line identifies number of the bus that handles the device. This corresponds to the physical connector that manages the hardware—03 in this case. You don't need this information for configuration, but it may be helpful in diagnosing problems. For instance, if you suspect bus problems, you could try moving the device to another bus or look up information in the /proc/bus/usb/devices pseudo-file on the configuration of the specified bus.
Device number The Dev# item identifies the number of the USB device on its bus. You don't need this information for configuring the device, but you might need it for debugging purposes.
Bus speed The Spd item, also on the first line, specifies the bus speed in megabits per second—480in this example. USB 2.0 devices normally communicate at this speed, but USB 1.0 and 1.1 devices communicate at a much more sedate 12Mbps. If you see this value but believe your device should be communicating at a faster speed, you should check that your hardware supports USB 2.0. If it does, look for the presence of an Enhanced Host Controller Interface (EHCI) driver in the Linux kernel, and be sure it's loaded. (Task 2.6, "Configure and Compile a Kernel," describes kernel configuration.)
Vendor and product IDs The Vendorand ProdIDcodes on the third line identify the device. In this example, Vendor=0686is reserved for Minolta products, while ProdID=400euniquely identifies the Minolta DiMAGE Scan Elite 5400. Linux auto-configuration tools look for this information when setting up new devices, and you'll need it to add entries for devices that your distribution doesn't explicitly support.
Adjusting the USB Hot-Plug Configuration
Once you have the USB vendor and product ID codes, you can begin modifying the udev configuration to support these devices. Most distributions that use the 2.6.x kernel use udev, which dynamically creates entries in the /devdirectory tree for your hardware. When udevworks well, it's pretty transparent; however, when it fails, it can require modifying some obscure configuration files. These files control the names, ownership, and permissions assigned to device files, among other things. Most distributions place these configuration files in the /etc/udev/rules.d directory. Packages can place udevrules files in this directory to ensure that the devices they use are given suitable device files. For instance, on a Fedora Core 5 system, the udev package installs default rules files, including 50-udev.rules, 50-udev-early.rules, and 51-hotplug.rules. On the same distribution, the sane-backendspackage installs the 60-libsane.rulesfile, expanding the set of udevrules. Each udevrules file must have a name that ends in .rules. Most rules files have names that begin with a number; these numbers determine the order in which the rules are implemented.
Before proceeding further, take some time to peruse the udev rules files. They may seem intimidating, but a general familiarity with their forms can be helpful. When creating new rules, you have two choices: modify an existing rules file or create a new rules file. The former option can be a bit simpler, but it runs the risk that your changes may be overwritten by package upgrades. Thus, you may want to create a new rules file.
Listing 2.1 shows a sample file, which you might name 61-minolta.rules.
Listing 2.1: Sample udev Rules File
SUBSYSTEM!="usb_device", ACTION!="add", GOTO="minolta_rules_end"
# Minolta|DiMAGE Scan Elite 5400
SYSFS{idVendor}=="0686", SYSFS{idProduct}=="400e", SYMLINK+="scan-elite"
MODE="0664", OWNER="root", GROUP="scanner"
LABEL="minolta_rules_end"
This file contains four configuration lines and a comment line (denoted by a leading hash mark, #). The first configuration line is a GOTOstatement—it tells udevto go to the line that's labeled minolta_rules_end(via the LABELstatement on the final line) when not configuring USB devices and when not adding entries. Your udevrules file should contain a line like this, although you may want to change the label you use to identify the end of the configuration block, on both this and the final configuration lines.
The second configuration line tells udev to add /dev filesystem entries for a device with a vendor ID of 0686 and a product ID of 400e. The device file created, in the case of USB devices, will be an entry in the /dev/bus/usbdirectory tree. Specifically, udevcreates a numbered subdirectory for each bus and a numbered device file for each device. This is where the bus number and device number from /proc/bus/usb/devicescan come in handy—they can point you to your USB device file. The second configuration line in Listing 2.1 also tells udev to create a symbolic link called scan-elite. This symbolic link appears in the /devdirectory and points to the real device file. The symbolic link is a handy shortcut for reaching the real device file, which is important for some programs but not for others. Without the symbolic link, you can never be sure what the device filename will be for a USB device since the device number on the bus and even the bus number can change when you unplug a device and plug it back in or when you reboot the computer.
The third configuration line in Listing 2.1 (beginning MODE=) is actually a continuation of the second line, as denoted by the backslash () that terminates the second line. This line specifies the mode, owner, and group of the device files that udevcreates. This information is particularly important for any device that should be accessible to ordinary users. In the absence of such lines, either in the rules files delivered with your software or in rules files you add, udev will probably create device files with insufficient permissions for ordinary users to access the device. Listing 2.1 causes udev to create a device file with root ownership, scanner group ownership, and 0664 permissions, enabling anybody in the scanner group to read from and write to the device file. Thus, if a user should be able to access the scanner, you can add that user to the scanner group.
Checking Your Changes
Unfortunately, udev won't pick up your changes immediately upon your making them. To have udev do so, you can stop and restart the udevd daemon process:
# ps ax | grep udevd 2685 ? S s 0:00 /sbin/udevd -d 2747 pts/0 R+ 0:00 grep udevd # kill 2685 # /sbin/udevd -d
These three commands locate the udevd process, kill it, and restart it. You should adjust the process ID number in the kill command based on the number output by the ps command. Phase 3 describes Linux process management in more detail.
After restarting udevd, you should attach and (if necessary) turn on your USB device. (If it's already connected, disconnect it first.) You should then check for the presence of a new device file in the /dev/bus/usb directory tree. Remember that the filename will probably change when you disconnect and reconnect the device! Check that the device file has the correct ownership and permissions, and look for a symbolic link, if your rules create one.
Beyond this basic test, you can test the device using appropriate software, such as VueScan (http://www.hamrick.com) for the Minolta film scanner used as an example. Be sure that appropriate users are able to access the hardware and that users who should not have access to the hardware are unable to do so.
Criteria for Completion
This task demonstrates configuration changes to enable access to USB hardware that's not automatically configured by Linux. You should be able to identify a USB device in the /proc/ bus/usb/devices file and use the information found there to create a new /etc/udev/ rules.d/ file to create suitable device files in the /dev/bus/usb directory tree.
Use the following table of contents to navigate to chapter excerpts, or click here to view Chapter 2 in its entirety.
Home:
Introduction
| ABOUT THE BOOK: |
| Hit the ground running with the street-smart training you'll find in Linux Administrator Street Smarts: A Real World Guide to Linux Certification Skills. Using a "year in the life" approach, it gives you an inside look at Linux administration, with key information organized around the actual day-to-day tasks, scenarios, and challenges you'll face in the field. This valuable training tool is loaded with hands-on, step-by-step exercises covering all phases of Linux administration. Purchase the book from Wiley Publishing |
| ABOUT THE AUTHOR: |
| Roderick W. Smith left a career in academia to pursue his passion for computers. He is particularly interested in Linux and Open Source Software, and has written several books. |
