|< Free Open Study >|| |
Computers have the ability to do a very wide range of things for you, but frequently only if you have the appropriate hardware installed. This section discusses some custom hardware devices installed on the case study system, and the support available for them.
This case study is based on Red Hat Linux 7.3, and some of the information in this section is specific to that distribution. However, hardware support for any Linux system really boils down to what the kernel itself supports. Since all distributions have the same kernel, much of this material is not distribution specific, and would be applicable to the other distributions covered in this book, and even others that are not covered. Things that are kernel specific and things that are Red Hat Linux specific are pointed out.
Iomega's ZIP drive is an extremely popular product. ZIP disks are 3.5-inch cartridges, roughly the same dimensions as floppy disks, that can store several hundred megabytes of data. ZIP drives are available in a number of interface formats; some are attached externally via the system's parallel port or a SCSI or USB interface, whereas others are internal and use the very common ATAPI IDE standard.
The Linux kernel supports ZIP drives in each of these formats. However, since each drive interface is quite different, the support for them varies. For example, if the ZIP drive uses a SCSI interface, then it appears literally identical to any other SCSI device. However, if the ZIP drive is an internal ATAPI drive, then it is supported as a standard IDE drive, just as would an IDE hard disk. USB ZIP drives are supported by a special USB device driver and exposed as SCSI devices. Finally, just to complicate things, ZIP drives on the parallel port are supported by a ZIP drive-specific device driver kernel module (called "ppa" or "imm" depending on the particular ZIP drive version), but are exposed to the system as SCSI devices.
There are four types of ZIP drive—parallel port, SCSI, USB, and IDE—and therefore four cases for configuring a ZIP drive. Each of these methods is fairly different at a low level, but in the end they all have the save result: a device file pointing to the disk that can be used to mount it. The three following sections discuss how ZIP drives are handled for SCSI, parallel port, and IDE cases; USB drives are discussed later in this chapter.
A SCSI ZIP drive is supported transparently as a SCSI disk by Linux's SCSI framework. This means that the ZIP drive will be exposed to the system as a standard SCSI device, having a name such as /dev/sda. The "/dev/sd" part denotes a SCSI disk; the "a" indicates that it is the first SCSI disk on the system. If you have a SCSI ZIP drive, then it may or may not be the first SCSI device, so you'll have to change "a" to another letter. For example, if your ZIP drive is the fourth SCSI device, it will be /dev/sdd.
The Linux kernel driver for SCSI devices is sd_mod (for "SCSI Disk") and is usually included as a kernel module on Red Hat Linux systems (and included in the initial ramdisk on systems that need it, as discussed in Chapter 4). The ZIP drive will appear as a simple disk on whatever SCSI host controller to which it is connected.
A parallel port ZIP drive contains special hardware that is actually a SCSI controller. The Linux kernel includes a device driver that can communicate with this hardware over the parallel port and expose the ZIP drive as a standard SCSI device. This takes the form of a second SCSI host controller; that is, if the system already has a SCSI controller card, these kernel drivers will appear as a second SCSI controller.
There are two versions of this parallel port/SCSI hardware, known as PPA and IMM. Linux includes drivers (named simply "ppa" and "imm", respectively) for both variants. The drivers themselves create a separate SCSI host controller for the device, and the ZIP drive will appear as the sole device attached to that controller. As with normal SCSI devices, parallel port ZIP drives will appear as /dev/hda, /dev/hdd, and so on.
An IDE ZIP drive is treated as an IDE floppy device. Linux includes a device driver that supports IDE floppy disk drives. IDE ZIP drives perhaps have more in common with IDE CD-ROM drives than IDE floppy drives, but they are treated as floppy drives nonetheless. That is, they are supported by the same device driver.
The IDE floppy disk device driver is named ide-floppy. Normally, Red Hat Linux has this driver built into the kernel (and not as a loadable module), so you shouldn't have to do anything, and the kernel should detect your ZIP drive on bootup. The device will appear as a normal IDE device, such as /dev/hda for the first IDE device, or /dev/hdd for the fourth. (The naming convention is similar to that of SCSI devices, mentioned earlier, except that "hd" is used instead of "sd".)
Red Hat Linux includes the ide-floppy device driver, which supports IDE ZIP drives as a built-in feature, rather than a loadable module. This makes it easy to detect ZIP drives (and, of course, other IDE floppy drives) on bootup. However, not all distributions do it this way, and some include ide-floppy as a kernel module.
On these systems, you may run into a scenario that may be confusing at first, especially if you're using the ide-scsi SCSI emulation module, which is mentioned in the section "Using a CD Writer" later in this chapter. Specifically, if that module is used and ide-floppy is compiled as a kernel module, then it's possible that the ide-scsi module can load before the ide-floppy module.
In this case, the ZIP drive might be managed by the ide-scsi module (rather than the ide-floppy module) and would be exposed to the system as a SCSI device instead of an IDE device. For example, it might be /dev/sdb instead of /dev/hdd. If you are using another distribution, or even simply a custom kernel on Red Hat Linux, you might run into this issue and should be aware of it. All that will change is the device name of the ZIP drive.
Once you have the appropriate kernel modules loaded, the ZIP drive will appear as a standard block disk device, so you can interact with it as you would with any such device. If you aren't yet sure what device name your ZIP drive is exposed as, you'll have to check your system's configuration. You can check by using the dmesg command or /var/log/messages to see how the kernel named the drive, or by looking at /etc/fstab to see how kudzu set up the mount points for the device.
There is a minor idiosyncracy to be aware of when using ZIP drives, and that is which partition you use. If you buy a ZIP disk, it will probably come preformatted with the FAT (File Allocation Table) filesystem. Normally you would expect this partition to be the first partition—for example, /dev/sda1 (if your ZIP drive is /dev/sda). However, this isn't the case, and by default new ZIP disks have the filesystem on the fourth partition—/dev/sda4 in the same example. You can alter this if you repartition the ZIP disk with the fdisk program, but it's something to be aware of when you use new disks, or if you wish to reformat a disk without repartitioning it (such as reformatting a ZIP disk with the standard Linux ext2 filesystem, which is definitely possible).
ZIP disks are factory partitioned to use the fourth partition as the actual data partition (such as /dev/sda4 or /dev/hdc4). On a related note, some ZIP drive manufacturers have a hardware setting that is intended to make this behavior invisible to the operating system, by hiding the partition table on ZIP disks inserted into it. Unfortunately, this behavior breaks Linux. If you have such a ZIP drive (and it works under Windows or another operating system, but not Linux), then there is probably a jumper on the device that you can change to disable the behavior.
Of course, you may never actually have to do this, because Red Hat Linux does it for you. When kudzu detects a ZIP drive, it not only configures the device drivers for it, but it also creates a mount point for the drive. Specifically, the directory /mnt/zip100.0 is created for 100MB ZIP drives, and a corresponding entry is created in /etc/fstab. (The fstab file is pretty simple, and is common to almost all Unix-like systems; you should check the manual page for fstab for details.)
So, to mount your ZIP drive, you probably don't have to do anything more than just type mount /zip100.0 and it will work. If you use a desktop environment such as KDE, icons for the drive will also be created for you automatically, in which case you can use them as well. However, should you need to do something with the drive or disk directly, it's useful to know how to find it, which was the purpose of this section.
The Universal Serial Bus (USB) is a standard for connecting a variety of hardware devices to a computer. Any number of nifty gadgets employ USB, such as MP3 players that use it to manage the playlist, PDAs that use USB to synchronize data with the computer, digital cameras that use USB to transfer images to the computer, and so on. USB support on Linux systems is primarily provided by the Linux kernel, meaning that the distribution doesn't have a great deal to do with it. This section discusses several example uses of USB with the case study system.
Generally, there isn't much you'll have to do to get USB working—at least, at the core. Chances are Red Hat Linux will detect your USB host controller hardware correctly and configure it for you. After that, all you have to do is plug in a USB device, and see whether it's recognized by the kernel (which is to say, whether the device is supported and has a kernel module available for it).
It's important to keep in mind that even once your device's driver is loaded, all that's happened is that access to it is exposed by the kernel to userspace programs. Another way to put it is that each USB device driver really just exposes a small API for interacting with the device. The userspace programs themselves are responsible for knowing how to use this mini-API. The API may take different forms, depending on the driver. Sometimes these are quite standard (such as USB storage devices, described later in this section), and sometimes they are quite complex (such as a USB MP3 player, also described later in this section).
Some example USB devices that I use with the case study system are presented in upcoming sections, along with information on how to configure them. The goal of these examples is to illustrate how the specific USB driver exposes access to the USB device in a way specific to that device, rather than provide a tutorial on how to use such devices. (By now, you should be able to work out the mechanics yourself, once you get some pointers.)
Before delving into the details, it helps to have an understanding of how the USB architecture in Linux generally works. There is ample documentation on Linux's USB architecture included with the kernel source code, so this is really just a brief introduction. In general USB support within Linux exists on four levels, as described next.
The first level is the core framework. This is the kernel module that implements the general USB system calls within the kernel, as well as an abstraction layer that applications interact with. That is, applications don't work directly with the USB controller hardware, but instead work with the core USB framework provided by the kernel. This level can be viewed as analogous to the general, high-level network APIs such as TCP/IP that run the same regardless of which hardware is being used.
The second level is the USB host controller driver. This takes the form of a device driver customly written for a specific piece of hardware. Referring to the analogy to the networking system, the USB host controller would be equivalent to an Ethernet card driver. However, USB manufacturers agreed on two standards for USB controller hardware: the Universal Host Controller Interface (UHCI) and the Open Host Controller Interface (OHCI).
USB controller manufacturers implement one or the other of these hardware specifications, meaning that there isn't as wide a variety of USB drivers as there is of Ethernet controllers, because many manufacturers' devices use the same drivers. In fact, only three common drivers exist for USB controllers: the usb-ohci driver for controllers that use the OHCI standard, and the usb-uhci and uhci drivers for UHCI cards. (The two drivers for UHCI have slightly different support for different hardware; if one driver doesn't work well with your configuration, you may wish to try the other.)
The third level of USB support is device-specific drivers. These are drivers that actually work with a specific USB device, such as a digital camera or MP3 player. You can think of the first two levels as simply providing USB connectivity, in that they merely allow the kernel and system to "see" USB devices. However, each device is different, so even if you already "see" the device, you still have to "speak its language" in order to use it. A number of drivers at this level implement support for various specific USB devices at the kernel level.
The final level of USB support is the kernel's "hotplug" mechanism, which is used for devices that are plugged in to a running system. When the kernel detects such an event, it invokes a program (specifically, /sbin/hotplug) that is responsible for identifying the device and loading the appropriate driver for it. Devices are identified by comparing their identifying string (which can be obtained from the device itself) to a list of supported identifiers that are mapped to kernel modules; the corresponding module is then loaded. The related files (containing these mappings and related scripts) live in the directory /etc/hotplug. The hotplug mechanism works for more than just USB—it also works with PCI and other similar hardware busses.
Digital photography is becoming increasingly popular as digital cameras become cheaper. This section will discuss how to connect such hardware to a Red Hat Linux system. The section "Working with Digital Cameras" later in this chapter discusses the application software you need to complete the circle. Many such digital cameras use USB (rather than the much slower RS-232 serial port or parallel port) to transfer images from the camera to the desktop computer for storage. Some of these cameras have USB drivers available for Linux.
The camera model used in this case study is a Kodak DC-280, though the model isn't really relevant; the same general information applies to any supported USB digital camera. Once the camera is plugged into the system's USB port, the usb-core driver will detect it, and the kernel will invoke the hotplug mechanism, which will load the camera-specific driver—in this case, dc2xx.
Once the driver is loaded, a new set of system calls is available to userspace applications. (The details of this API are only of interest to developers, so I won't go into them here.) The job still isn't quite complete, though. You still need a program to make use of these syscalls. Probably the most popular such program is the gphoto program discussed later in this chapter. Once you have gphoto running, you'll be able to use your digital camera just as you would with any other operating system.
Many devices, such as digital cameras, PDAs, MP3 players, and more, employ common and inexpensive flash cards for storage. Generally these cards use either the Compact Flash (CF) standard, or the SmartMedia (SM) standard, or some other format. In the case of CF and SM cards, you can also purchase widely available, inexpensive readers for the cards. Typically these readers are simply a small plastic port into which the flash cards are inserted, and that connect to the computer via USB.
Many of these readers adhere to a hardware specification standard for USB mass storage devices. In fact, this standard supports many things other than just flash card readers; it also includes such nifty gizmos as some keychain storage devices, USB ZIP drives, USB CD writers, and so on. The Linux kernel includes a driver for USB mass storage devices, named usb-storage. If you have a reader (or other device) that obeys the USB mass storage standard, the hotplug mechanism can detect it and load the usb-storage driver automatically.
Unlike the digital camera drivers just described, the usb-storage driver doesn't require any special software, because it doesn't use any custom system calls. Instead, the usb-storage driver simply exposes any devices it detects as standard SCSI disks. For example, if you already have two SCSI disks connected to your system and then connect a flash card reader, it will appear as the third SCSI disk: /dev/sdc. You can then mount, format, or even partition these devices, exactly as you would with any other SCSI storage device.
Another popular device is the portable MP3 player, which allows a user to store and play large amounts of music in the high-quality MPEG-2 Layer 3 (MP3) standard format. These devices are frequently connected to the computer via USB.
Some of the devices may actually use the usb-storage mechanism just discussed to allow you to copy files directly to and from them. However, many use some other scheme—that is, a custom API over USB. For some of these devices for which adequate technical information is available from the manufacturer (or that can be reverse-engineered independently), Linux USB drivers are available. For example, many Rio devices produced by SonicBlue are supported by the rio500 USB driver. As with the digital camera, connecting a Rio-500 (for example) to the system will cause the kernel to load the correct driver by invoking the hotplug mechanism. At that point, a set of system calls will be available—this time, for managing the contents of the Rio-500.
Again, as with the digital camera, you'll need a special program that is written to use these system calls. One such program is the Rio 500 project at http://www.rio500.sourceforge.net. This is actually the home of the Linux kernel USB driver module that provides connectivity to the Rio, but this URL also gives you access to userspace programs you can use to manage the device's contents. The tools allow you to store MP3s to the Rio, remove them, create playlists, and so on. Graphical tools are also available.
Linux has drivers for many other USB devices, and the list is growing. There is support for USB joysticks and gamepads, some USB network adapters, USB web cameras, and so on. This book obviously cannot discuss all of these, but now that you've seen some examples of using USB devices with Linux, you should be able to figure out how to add others.
Generally, just remember the basic procedure: When you plug in a device, the driver for the USB host controller will detect it, and the kernel will invoke the hotplug program to attempt to locate and load a driver for it. After that, you'll need a program that understands how to use the driver (as with the digital cameras and MP3 players), or you'll have to interact with the device (as with the SCSI devices exposed by the usb-storage driver).
Linux's support for USB has its warts; sometimes devices aren't detected by the drivers (especially when the devices are newer than the driver), and sometimes support for devices is spotty or slow, but overall it works pretty well. In some cases—especially with USB input devices such as keyboards, mice, and joysticks— you may have to do a bit more work to get them working correctly, but by now this shouldn't be difficult. Just remember how the system works, and know where to start. USB on Linux really isn't that hard.
Using writable CDs has become a very affordable way to store data, whether it's a backup of your operating system, a copy of important data, an album of photos from your latest family reunion, or a mix of tracks from your favorite music CD. Red Hat Linux makes it fairly painless to use these devices.
Red Hat Linux tries to take a unified approach. Generally, Red Hat Linux tries to treat devices as SCSI devices as much as possible. Linux includes a kernel module known as ide-scsi that emulates the SCSI protocol on behalf of IDE devices. This allows IDE devices to be exposed as SCSI devices, and Red Hat Linux can use this module.
When the ide-scsi module is loaded (via a command such as modprobe or insmod), the driver scans the IDE bus (or busses), locates all IDE drives, and then begins treating them as SCSI devices, translating SCSI calls to IDE calls. Thus, if an IDE ZIP drive is present on the system, after the ide-scsi module is loaded it will be available as a SCSI disk, indistinguishable from other SCSI devices.
This ability to treat any disk as a SCSI disk is extremely useful, and really pretty slick if you think about it. It's used repeatedly within Red Hat Linux, as you've seen before and will continue to see in the rest of this chapter. Many of the sections that follow refer to this notion of SCSI emulation.
When Red Hat Linux boots, it will load the ide-scsi module if necessary (that is, if any devices—such as CD writers or ZIP drives—are present and require it).
Generally, whenever you connect a ZIP drive to the system, Red Hat Linux will detect it by using the kudzu program invoked from /etc/rc.d/rc.sysinit on system bootup, as discussed in Chapter 4. Because of Red Hat's use of the ide-scsi module, kudzu usually only has to worry about detecting SCSI devices, rather than both IDE and SCSI. Once the disk is detected, kudzu will prepare the device for use.
If your CD writer is a SCSI drive, then you're all set, and you don't need to do anything else. However, if it's an IDE writer, then the ide-scsi module is required, so that the IDE device is exposed as a SCSI device for the CD-writing software to use. Fortunately, Red Hat Linux 7.3 detects IDE CD writers, and automatically configures the ide-scsi module for you, for that device.
You can accomplish this by passing a parameter to the kernel from the boot loader (which is usually GRUB). The argument that needs to be passed is [IDE device]=ide-scsi; for example, if your CD writer is normally the third IDE device, it would appear as /dev/hdc. In this case, you'd need to pass the kernel argument hdc=ide-scsi. Red Hat Linux does this for you when you install it.
This means that you probably won't have to do anything in order to get your CD writer working, if it was present when you installed the system. However, if you add it after the system was installed, you'll have to add the line to the boot loader's configuration yourself. (Actually, the kudzu program discussed in Chapter 4 may also do this for you, when you reboot the system. Again, though, it's useful to know what's going on.)
See the section "Using the GRUB Boot Loader" in Chapter 4 for more information and references to the GRUB boot loader.
Once the system is set up to expose the CD writer as a SCSI device, you need only use the appropriate program to burn a CD. Two popular programs, cdrecord and xcdroast, are discussed later in this chapter, in the section "Media and Entertainment."
Modern computers usually have some kind of hardware 3D acceleration in the video card. This acceleration is used by games, and some kinds of technical and engineering software (such as CAD tools and medical imaging). Since this is hardware, these cards have to be supported under Linux with a device driver.
As you read in Chapter 3, the vast majority of Linux systems use XFree86 teamed with some kind of desktop or window manager as the graphical interface. As a result, XFree86 has to support 3D hardware on Linux systems. This generally means that XFree86 has to have a driver for the video card so it can run within the X server. Additionally, many applications that use 3D do so by using the OpenGL programming API, and so practically speaking, support for 3D under Linux also requires an implementation of OpenGL.
It can definitely be argued that 3D support on Linux systems is weak, though this situation is improving rapidly, especially with recent versions of XFree86. The main difficulties are that many vendors' 3D cards do not have drivers and that there is no hardware-accelerated OpenGL implementation for that hardware.
Some vendors release adequate programming information for their hardware, and so XFree86 itself supports 3D acceleration on these cards. Other vendors instead provide downloadable drivers for XFree86 that provide hardware acceleration. In this case, the drivers are frequently not free software or open source, even though source code may be available for them. You'll frequently have to install the driver in a directory and modify the XFree86 configuration to load the driver, which is distributed as a dynamically loadable library.
See "The Origins of Linux" and "GNU and Linux: The Operating System of Champions" in Chapter 1, and "Open Source vs. Free Software" in Chapter 2 for details on the distinction between free software and open source.
However, even if hardware acceleration is enabled, software still needs to be able to access that acceleration. The OpenGL specification is widely used, but it's not technically a standard. An open source package known as Mesa is intended to be source-code compatible with OpenGL (meaning that it implements the same API), but even this library is only able to provide hardware acceleration for chips whose API it understands.
Consequently, many times the vendors who release their own proprietary drivers for XFree86 also include an implementation of OpenGL, so that software can actually take advantage of the accelerations. The plus side of this approach is that you get good hardware acceleration supported by the vendor, but the downside is that you'll have to install the drivers manually, since they aren't included with the distribution.
The video card in the case study is an NVidia TNT2 M64. NVidia is of the latter type of vendor—that is, it supplies its own drivers for XFree86 to provide hardware acceleration under Linux. Unfortunately, NVidia's drivers will obviously only work with its cards.
The bottom line is that if 3D acceleration on your video card isn't supported by XFree86, your card's manufacturer will have to provide that support. Each vendor can do things different ways, so there is no general rule of thumb. The only thing you can do is visit your card manufacturer's web site to see what support it provides, and then follow the instructions the manufacturer gives for installing the drivers. Fortunately, this usually isn't too complicated a task.
So far, you've read about the core desktop and productivity software, as well as the hardware used on the case study system. Now you'll read about the extra, less essential (but no less useful) software used on the case study system, starting with media and entertainment software.
|< Free Open Study >|| |