4. Kernel printer devices
There are two completely different device drivers for the parallel
port; which one you are using depends on your kernel version (which
you can find out with the command uname
-a). The driver changed in Linux 2.1.33; essentially all
current systems will be running kernel 2.2 or later, so you'll
probably want to skip ahead to the parport driver section.
A few details are the same for both styles of driver. Most
notably, many people have found that Linux will not detect their
parallel port unless they disable "Plug and Play" in their PC BIOS.
(This is no surprise; the track record for PnP of non-PCI devices
with Windows and elsewhere has been something of a disaster).
4.1. The lp device (kernels <=2.1.32)
The Linux kernel (<=2.1.32), assuming you have compiled in or
loaded the lp device (the output of cat /proc/devices should include the device lp if it is
loaded), provides one or more of /dev/lp0,/dev/lp1, and /dev/lp2.
These are NOT assigned dynamically, rather, each corresponds to a
specific hardware I/O address. This means that your first printer
may be lp0 or lp1
depending on your hardware. Just try both.
A few users have reported that their bidirectional lp ports aren't
detected if they use an older unidirectional printer cable. Check
that you've got a decent cable.
One cannot run the plip and lp drivers at the same time on any
given port (under 2.0, anyway). You can, however, have one or the
other driver loaded at any given time either manually, or by
kerneld with version 2.x (and later 1.3.x) kernels. By carefully
setting the interrupts and such, you can supposedly run plip on
one port and lp on the other. One person did so by editing the
drivers; I eagerly await a success report of someone doing so with
only a clever command line.
There is a little utility called tunelp floating about with which you, as root, can tune the
Linux 2.0 lp device's interrupt usage, polling rate, and other
When the lp driver is built into the kernel, the kernel will
accept an lp= option to set
interrupts and io addresses:
When the lp driver is built in to the kernel, you may use the
LILO/LOADLIN command line to set the port addresses and interrupts
that the driver will use.
For example: lp=0x378,0 or lp=0x278,5,0x378,7 **
Note that if this feature is used, you must specify *all* the ports
you want considered, there are no defaults. You can disable a
built-in driver with lp=0.
When loaded as a module, it is possible to specify io addresses
and interrupt lines on the insmod command line (or in/etc/conf.modules so as to affect kerneld)
using the usual module argument syntax. The parameters areio=port0,port1,port2 and irq=irq0,irq1,irq2. Read the man page forinsmod for more information on this.
**For those of you who can never find the standard port
numbers when you need them, they are as in the second example
above. The other port (lp0) is at 0x3bc.
I've no idea what interrupt it usually uses.
The source code for the Linux 2.0 parallel port driver is in
4.2. The parport device (kernels >= 2.1.33)
Beginning with kernel 2.1.33 (and available as a patch for kernel
2.0.30), the lp device is merely a client of the new parport
device. The addition of the parport device corrects a number of
the problems that plague the old lp device driver - it can share
the port with other drivers, it dynamically assigns available
parallel ports to device numbers rather than enforcing a fixed
correspondence between I/O addresses and port numbers, and so
The advent of the parport device has enabled a whole flock of new
parallel-port drivers for things like Zip drives, Backpack CD-ROMs
and disks, and so forth. Some of these are also available in
versions for 2.0 kernels; look around on the web.
The main difference that you will notice, so far as printing goes,
is that parport-based kernels dynamically assign lp devices to
parallel ports. So what was lp1 under Linux 2.0 may well be lp0
under Linux 2.2. Be sure to check this if you upgrade from an
lp-driver kernel to a parport-driver kernel.
The most popular problems with this device seems to stem from
- The Distribution
Some GNU/Linux distributions don't ship with a properly setup /etc/modules.conf (or /etc/conf.modules), so the driver isn't loaded properly when you need it to be. With a recent
modutils, the proper magical lines from modules.conf seem to be:
alias /dev/printers lp # only for devfs?
alias /dev/lp* lp # only for devfs?
alias parport_lowlevel parport_pc # missing in Red Hat 6.0-6.1
- The BIOS
Many PC BIOSes will make the parallel port into a Plug-and-Play device. This just adds needless complexity to a
perfectly simple device that is nearly always present; turn
off the PnP setting for your parallel port ("LPT1" in many
BIOSes) if your parallel port isn't detected by the Linux
driver. The correct setting is often called "legacy", "ISA",
or "0x378", but probably not "disabled".
You can also read the parport documentation in your kernel sources, or
look at the parport web
4.3. Serial devices
Serial devices are usually called something like/dev/ttyS1 under Linux. The utility stty will allow you to interactively view or
set the settings for a serial port; setserial will allow you to control a few
extended attributes and configure IRQs and I/O addresses for
non-standard ports. Further discussion of serial ports under
Linux may be found in the Serial-HOWTO.
When using a slow serial printer with flow control, you may find
that some of your print jobs get truncated. This may be due to
the serial port, whose default behavior is to purge any
untransmitted characters from its buffer 30 seconds after the port
device is closed. The buffer can hold up to 4096 characters, and
if your printer uses flow control and is slow enough that it can't
accept all the data from the buffer within 30 seconds after
printing software has closed the serial port, the tail end of the
buffer's contents will be lost. If the command cat file > /dev/ttyS2 produces complete
printouts for short files but truncated ones for longer files, you
may have this condition.
The 30 second interval can be adjusted through the
"closing_wait" command-line option of setserial (version
2.12 and later). A machine's serial ports are usually initialized
by a call to setserial in the rc.serial boot file. The call for
the printing serial port can be modified to set the
closing_wait at the same time as it sets that port's other
4.4. USB Devices
4.4.1. USB 1.1
Linux supports USB pretty well. USB should work with any late-model 2.2 kernel, and any 2.4 kernel or newer. Of course you need kernel support for USB, either linked in or through a module (recommended).
If you have a modular kernel, the following modules need to be loaded:
Which one of usb-uhci.o or uhci.o or usb-ohci.o you need depends on the kind of motherboard or adaptor you have. Intel and Via motherboards and Via based adaptors are UHCI (you can use either usb-uhci.o or uhci.o). You can find out which type of HCI (Host Controller Interface) you have with lspci -v|grep HCI
4.4.2. USB 2.0
To get high speed transfers out of a USB 2.0 capable device you must attach it to an USB 2.0 controller and use the EHCI driver (ehci-hcd.o). A recent 2.4 kernel or higher is recommended if you want to use USB 2.0.
One thing to remember is that USB devices are dynamically allocated. A USB printer gets assigned a device file (/dev/usb/lp*) when it is turned on or connected. This could mean that print jobs are sent to the wrong printer because you turned them on in a certain order. CUPS uses special Uri's containing manufacturer, model and printer serial number to keep sending the jobs to the correct physical printer.
Although most USB printers work fine on Linux, there are exceptions. For example the new MF devices from Epson (Stylus CX3200/CX5200) return garbage when one polls the IEEE-1284 ID string via IOCTL, for example
with the code of the CUPS "usb" backend. Whereas one can poll the ID string via an Epson-proprietary method.
Till Kamppeter has written some tools to retrieve the device ID string from USB printers. getusbprinterid.pl and usb_id_test.c are the same thing but respectively in Perl and C. As mentioned above, the new MF devices from Epson are an exception, but the "Epson proprietary method" is implemented in the ttink tool of the MTink package.
More documentation about USB is available at the Linux USB Website.