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).
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
options.
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. Syntax: lp=port0[,irq0[,port1[,irq1[,port2[,irq2]]]]] 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 /usr/src/linux/drivers/char/lp.c.
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 forth.
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 misconfiguration:
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
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 site.
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 parameters.
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:
usb-core.o
usb-uhci.o or uhci.o or usb-ohci.o
printer.o
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
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.