TOC PREV NEXT INDEX

QNX Logo

12 Connecting Printers, Terminals and Other I/O Devices

This chapter covers the following topics:

Connecting printers

[Author's Comments: check sequencing of print topics: lpd-spooler-remote with lpd & with spooler] RTP provides two separate mechanisms for printing:

Printing with lpr

This printing mechanism uses the standard UNIX-like lpr utility. You need to know about three main components:

lp* utilities

RTP provides several utilities to print files and find out what is going on; here's how to use them:

To do this:
 		Use this utility
Print a file
 		lpr
Examine a print spool
 		lprq
Remove a print job
 		lprrm
Control the printing system (root only)
 		lprc (also see "Line printer administration")

Line printer administration

The lprc program provides root with local control over line printer activity. Here are the program's major commands and their intended uses; see Utilities Reference for the command format and the full list of commands.

abort and start

The abort command terminates an active spooling daemon on the local host immediately and then disables printing (preventing new daemons from being started by lpr). This is normally used to forcibly restart a hung line printer daemon (e.g. when lprq reports that a daemon is present but nothing is happening). The abort command doesn't remove any jobs from the spool queue (use lprrm instead). The start command enables printing and asks lpd to start printing jobs.

enable and disable

These commands allow spooling in the local queue to be turned on or off in order to allow or prevent lpr from putting new jobs in the spool queue. You may want to use this option to turn spooling off while testing new printer filters for example, as the root user can still use lpr to put jobs in the queue (but no one else can). The other main use of this option is to prevent users from putting jobs in the queue when the printer is expected to be unavailable for a long time.

restart

The restart command allows ordinary users to restart printer daemons when lprq reports that no daemon is present.

stop

The stop command halts a spooling daemon after the current job completes; this also disables printing. This is a clean way to shut a printer down for maintenance. Note that users can still enter jobs in a spool queue while a printer is stopped.

topq

The topq command places selected jobs at the top of a printer queue. This can be used to promote high-priority jobs (lpr places jobs in the queue in the order they are received).

Setting up /etc/printcap

The /etc/printcap database contains one or more entries per printer. This file is not present when you first install QNX 6, you have to create one to suit your printing needs.

A typical setup

Here is a basic /etc/printcap file you can modify: 

#This entry describes the Tech Pubs printer
lpt1|tpptr|printer in techpubs department:\
  :lp=/dev/par1:\
  :sd=/usr/spool/output/lpt1:\
  :lf=/usr/adm/lpd-errs:\
  :mx#0:

Each entry in the /etc/printcap file describes a printer. Comments start with # (pound sign). An entry consists of a number of fields separated by : (colon) characters. In the example above, each field is on a separate line, but you can string the fields together on one line as long as they are separated by a colon.

If you put several fields on one line, remember that the parser requires at least one space between two colons.

Here's what each line means: 

lpt1|tpptr|printer in techpubs department:\

This first line gives the known names for the printer, separated by | (bar) characters. The first name is conventionally a number. The second name is the most common abbreviation for the printer; the last name should be a long name fully identifying the printer. The second name should contain no blanks; the last name may well contain blanks for readability. Entries may continue onto multiple lines by giving a \ (backslash) as the last character of a line. Empty fields may be included for readability. 

:lp=/dev/par1:\

This line gives the name of the device to open for output (the default is /dev/lp). 

:sd=/usr/spool/output/lpt1:\

This line sets the spooling directory (the default is /usr/spool/output/lpd). Each printer should have a separate spooling directory; if it doesn't, jobs will be printed on different printers depending on which printer daemon starts first. By convention, the name of the spooling directory has the same name as its associated printer. Make sure you create the named spooling directory before you print. 

:lf=/usr/adm/lpd-errs:\

This line provides a file to take printing error messages (by default, errors are sent to the console).

Sometimes errors sent to standard error output don't appear in the log file. The use of syslogd is therefore highly recommended.
 

:mx#0:

This line removes the default limits on the size of the spooling buffer.

Printers on serial lines

When a printer is connected via a serial line it must have the proper baud rate and terminal modes set. The following example is for a DecWriter III printer connected locally via a 1200 baud serial line. 

lp|LA-180 DecWriter III:\
 :lp=/dev/lp:br#1200:fs#06320:\
 :tr=\f:of=/usr/lib/lpf:lf=/usr/adm/lpd-errs:
lp

Specifies the file name to open for output.

br

Sets the baud rate for the tty line

fs

Sets CRMOD, no parity, and XTABS.

[Author's Comments: (@@how does the user know what these flags mean? there is no explanation for ttcompat in Utilities Reference, /etc/printcap]

tr=\f

Indicates that a form feed should be printed when the queue empties so the paper can be torn off without turning the printer offline and pressing form feed.

of=/usr/lib/lpf

Specifies that the filter program lpf should be used for printing the files (more about filters later).

lf=/usr/adm/lpd-errs

Causes errors to be written to the file /usr/adm/lpd-errs instead of the console.

Remote printers

Printers that reside on remote hosts should have an empty lp entry. For example, the following /etc/printcap entry would send output to the printer named lp on the machine ucbvax: 

lp|default line printer:\
 :lp=:rm=ucbvax:rp=lp:sd=/usr/spool/vaxlpd:

The rm entry is the name of the remote machine to connect to; this name must be a known hostname for a machine on the network. The rp capability indicates that the name of the remote printer is lp (here it could be left out since this is the default value). The sd entry specifies /usr/spool/vaxlpd as the spooling directory instead of the default pathname of /usr/spool/output/lpd.

Filters

Filters are used to handle device dependencies and accounting functions. Output filters are used when accounting is not needed or when all text data must be passed through a filter. An output filter is not suitable for accounting purposes because it is started only once, all text files are filtered through it, it does not pass owners' login names, and it doesn't identify the beginning and end of jobs. Input filters are started for each file printed and do accounting if there's an af entry. If entries for both input and output filters are specified, the output filter is used only to print the banner page; it's then stopped to allow input filters to access the printer.

Here's an example of a printer that requires output filters: 

va|varian|Benson-Varian:\
 :lp=/dev/va0:sd=/usr/spool/vad:of=/usr/lib/vpf:\
 :tf=/usr/lib/rvcat:mx#2000:pl#58:px=2112:py=1700:tr=\f:

The tf entry specifies /usr/lib/rvcat as the filter to be used in printing troff output. This filter is needed to set the device into print mode for text and into plot mode for printing troff files and raster images. Note that the page length is set to 58 lines by the pl entry for 8.5- by 11-inch fan-fold paper. To enable accounting, the varian entry would be augmented with an af filter: 

va|varian|Benson-Varian:\
 :lp=/dev/va0:sd=/usr/spool/vad:of=/usr/lib/vpf:\
 :if=/usr/lib/vpf:tf=/usr/lib/rvcat:af=/usr/adm/vaacct:\
 :mx#2000:pl#58:px=2112:py=1700:tr=\f:


The RTP distribution does not provide print filters, you have to either port them from another UNIX-type OS or write your own. RTP users unfamiliar with UNIX might find this to be a daunting task. RTP provides an alternative printing system to these standard UNIX-like lp* utilities, it uses a spooling system that provides print drivers for specific families of currently popular printers (see spooler in Utilities Reference).

Filter specifications

Filters are spawned by lpd; their standard input is the data to be printed, standard output is the printer. The standard error is attached to the lf file for logging errors (or syslogd may be used). A filter must return a 0 exit code if there were no errors, 1 if the job should be reprinted, and 2 if the job should be thrown away.

When lprrm sends a kill signal to the lpd process controlling printing, it sends SIGINT signal to all filters and descendants of filters. This signal can be trapped by filters that need to do cleanup operations such as deleting temporary files.

Arguments passed to a filter depend on its type. The of filter is called with the following arguments: 

filter -wwidth -llength

The width and length values come from the pw and pl entries in the /etc/printcap database. The if filter is called with the following arguments: 

filter [-c] -wwidth -llength -iindent -nlogin -hhost acct_file

The optional -c flag is used only when control characters are to be passed uninterpreted to the printer (when using the -l option of lpr to print the file). The -w and -l parameters are the same as for the of filter. The -n and -h parameters specify the login name and hostname of the job owner. The last argument is the name of the accounting file from /etc/printcap. All other filters are called with these arguments: 

filter -xwidth -ylength -nlogin -hhost acct_file

The -x and -y options specify the horizontal and vertical page size in pixels (from the px and py entries in the /etc/printcap file). The rest of the arguments are the same as for the if filter.

Access control

Local access to queues is controlled with the rg entry in the /etc/printcap file: 

:rg=lprgroup:

Users must be in the group lprgroup to submit jobs to the specified printer. The default is to allow all users access. Note that once the files are in the local queue, they can be printed locally or forwarded to another host, depending on the configuration.

Remote access is controlled by listing the hosts in either /etc/hosts.equiv or /etc/hosts.lpd file, one host per line. Note that other utilities also use /etc/hosts.equiv to determine which hosts are equivalent (e.g. see rlogin in Utilities Reference).

The file /etc/hosts.lpd is used only to control which hosts have printer access. To allow access only to those remote users with accounts on the local host, use the rs printcap entry: 

:rs:

Some /etc/printcap examples

This section gives you some examples to show you how to set up your printer descriptions; see also /etc/printcap in Utilities Reference.

For a single printer

A local (node1) /etc/printcap, assuming the printer is /dev/par1, might be as follows: 

lpt1:\
:lp=/dev/par1:

This file is very short and basic. All it does is give the printer connected to /dev/par1 a name of lpt1. No other capabilities need to be described because the defaults will suffice for such a simple case. To access this printer, you would specify -Plpt1 with the lpr command or set the PRINTER environment variable to lpt1.

Make sure the spool directory exists. You can set the pathname for this directory using the (sd) option in /etc/printcap or use the default pathname, /usr/spool/output/lpd.

A remote /etc/printcap on node2 might be as follows: 

rlpt1:\
:rm=node1:rp=lpt1:

This file specifies the remote host with the printer named lpt1 to be node1. The local name, rlpt1, is used by local clients and could be the same as the remote name lpt1.

For multiple printers

You should define multiple printers carefully, because the default capabilities won't be suitable for all printers. For example, the spool directory (sd) wisely restricts each printer to its own unique spool area.

The following example builds on the previous one by adding another printer definition for host node1.

A local /etc/printcap on node1: 

lpt1:\
  :lp=/dev/par1:sd=/usr/spool/output/lpt1:

lpt2:\
  :lp=/dev/par2:sd=/usr/spool/output/lpt2:

This file specifies two printers:

A remote /etc/printcap on node2: 

lpt1:\
  :rm=node1:rp=lpt1:sd=/usr/spool/output/lpt1:

lpt2:\
  :rm=node1:rp=lpt2:sd=/usr/spool/output/lpt2:
For local and remote printers

From the previous example, lpt2 has been physically relocated to node2. The /etc/printcap file on both node1 and node2 will have to be changed. Likewise, the /etc/printcap on node3 will also need changing to reflect the different remote host (rm) for lpt2.

The /etc/printcap on node1: 

lpt1:\
  :lp=/dev/par1:sd=/usr/spool/output/lpt1:

lpt2:\
  :rm=node2:rp=lpt2:sd=/usr/spool/output/lpt2:

The /etc/printcap on node2: 

lpt1:\
  :rm=node1:rp=lpt1:sd=/usr/spool/output/lpt1:

lpt2:\
  :lp=/dev/par1:sd=/usr/spool/output/lpt2:

The /etc/printcap on node3: 

lpt1:\
  :rm=node1:rp=lpt1:sd=/usr/spool/output/lpt1:

lpt2:\ 
  :rm=node2:rp=lpt2:sd=/usr/spool/output/lpt2:

Understanding lpr error messages

The following error messages from the lp* print utilities may help you troubleshoot your printing problems:

lpr error messages
lpr: filename: copyfile is too large

The submitted file was larger than the printer's maximum file size, as defined by the mx capability in its printcap entry.

lpr: printer: unknown printer

The printer wasn't found in the /etc/printcap database; could be a typo or a missing or incorrect entry in the /etc/printcap file.

lpr: printer: jobs queued, but cannot start daemon

The connection to lpd on the local machine failed, probably because the printer server has died or is hung. A superuser can restart lpd by typing:

/usr/bin/lpd

You can also check the state of the master printer daemon:

sin -P lpd

Another possibility is that lpr isn't setuid to root and setgid to group daemon. You can check by typing:

ls -lg /usr/bin/lpr
 lpr: printer: printer queue is disabled

This means the queue was turned off with: lprc disable printer to prevent lpr from putting files in the queue. This is usually done when a printer is going to be down for a long time. A superuser can turn the printer back on using lprc.

lprq error messages
waiting for printer to become ready (offline ?)

The daemon couldn't open the printer device. This can happen for several reasons (e.g. the printer is offline or out of paper, or the paper is jammed). The actual reason depends on the meaning of error codes returned by the system device driver and some printers cannot supply enough information to distinguish when a printer is offline or having trouble, especially if connected through a serial line. A different possible cause of this message is that some other process, such as an output filter, has an exclusive open on the device: all you can do in this case is kill off the offending program(s) and restart the printer with lprc

printer is ready and printing

The lprq program checks to see if a daemon process exists for printer and prints the file status located in the spooling directory. If the daemon is hung, a superuser can use lprc to abort the current daemon and start a new one.

waiting for host to come up

This implies that there's a daemon trying to connect to the remote machine named host to send the files in the local queue. If the remote machine is up, lpd on the remote machine is probably dead or hung and should be restarted.

sending to host

The files should be in the process of being transferred to the remote host. If not, the local daemon should be aborted and started using lprc.

Warning: printer is down

The printer has been marked as being unavailable with lprc.

Warning: no daemon present

The lpd process overseeing the spooling queue, as specified in the lock file in that directory, doesn't exist. This normally occurs only when the daemon has unexpectedly died. Check the error log file for the printer and the syslogd log to diagnose the problem. To restart an lpd, type: lprc restart printer.

no space on remote; waiting for queue to drain

This implies that there isn't enough disk space on the remote machine. If the file is large enough, there will never be enough space on the remote (even after the queue on the remote is empty). The solution here is to move the spooling queue or make more free space on the remote machine.

lprrm error messages
lprrm: printer: cannot restart printer daemon

This case is the same as when lpr prints that the daemon can't be started.

lprc error messages
couldn't start printer

This case is the same as when lpr reports that the daemon can't be started.

cannot examine spool directory

Error messages beginning with cannot are usually because of incorrect ownership or protection mode of the lock file, spooling directory, or the lprc program.

lpd error messages

The lpd program can log many different messages using syslogd. Most of these messages are about files that can't be opened and usually imply that the /etc/printcap file or the protection modes of the files are incorrect. Files may also be inaccessible if people bypass the lpr program.

In addition to messages generated by lpd, any of the filters that lpd spawns may log messages to the syslog file or to the error log file (the file specified in the lf entry in /etc/printcap). If you want to debug problems, run syslogd.

Printing with spooler

RTP provides the spooler utility as an alternative printing mechanism to the standard UNIX-like lpr utility. For more information on spooler, see Utilities Reference. The spooler utility is usually started by an enumerator when you start RTP.

Photon applications use spooler for printing. When you start spooler, it sets up a fake directory as a pathname space for each printer connected and adds a properties file constructed from information obtained from general printer configuration files. The standard RTP distribution provides general configuration files (in /etc/printers) for four of the most popular types of printers currently in use: Canon (bjc.cfg), Epson (epson.cfg), HP (pcl.cfg), and PostScript (ps.cfg).

To start a print job, the Photon application sends the file to be printed to the fake directory (dev/printers/printer_name/spool). The Photon application may construct another configuration file for the user-selected printer depending on optional information entered by the user. When the spooler sees the print job, it invokes a filter to deal with it. The filter adjusts the file to conform to the configuration needed and sends it to the printer.

Here's what spooler does to print a file:


Normally, spooler stores a file to be printed in a directory on disk, then tells the filter where to get the file. If you need to cut down on disk memory, you can used the -F option of spooler to disable print file spooling. This option causes spooler to send sections of a file to be printed, directly to a FIFO buffer in piecemeal fashion; the filter receives data to be printed from the FIFO and prints that part of the file. When the buffer has been emptied, spooler loads the next section of the file into the buffer, and so on until the whole file has been printed.

Remote printing

To demonstrate the essential elements of remote printing using Qnet, the native QNX 6 networking manager, and TCP/IP, we'll take a look at how you would do it using a simple two-node network. Suppose you have two machines running under RTP. The machines are connected via a crossover Ethernet cable plugged into a network interface card (NIC) on each machine, forming a simple two-node network. One of the machines has a printer plugged into its parallel port, we'll call this machine the printing_node; the other machine has files to be printed, we'll call this one the sending_node.

Remote printing over Qnet

[Author's Comments: is there any other way than printing to /net/nodename/dev/par1 ? ]

Remote printing over TCP/IP using lpr

To print a file from the sending_node using lpr, here's what you need:

Here are the tasks you need to perform to obtain each of these elements:

You need to be root to perform these tasks

Somewhere to store files waiting to be printed

The method used to store print jobs is called spooling [Author's Comments: should I include a detailed description of spooling?] . Each node must have a spooling directory to hold the files to be printed. By default, the pathname for this directory is /usr/spool/output/lpd/ (you can change the pathname of the spooling directory in the /etc/printcap file). If this directory does not exist, you must create it, on both nodes.

The lpd command will not work without a spooling directory and it won't tell you why. That's why it's a good idea to run the system logger (see syslogd in Utilities Reference) when you are trying to debug printing problems; then you can check for error messages in /var/log/syslog.

Some knowledge about the printer being used

Before anything can be printed, the nodes must know something about the specific printer being used. A description of the printer is kept in a file (/etc/printcap) on each node. As a minimum, the nodes will need to know where the printer is located: the sending_node needs to know which remote node has the printer and the printing_node needs to know which port the printer is plugged into. The following entries satisfy this minimal level of printer description:

In the /etc/printcap on the printing_node, enter: 

lpt1:\
  :lp=/dev/par1:

In the /etc/printcap on the sending_node, enter: 

rlpt1:\
   :rm=printing_node:rp=lpt1:

As you see, these entries refer to the printer as lpt1 on the printing_node and rlpt1 on the sending_node. This is purely a matter of choice: you can call them Fred and Ginger if you like; you can even use the same name on each node (e.g. Fred and Fred). We have named them this way to be able to differentiate between the two.

On the printing_node, the printer known as lpt1 is plugged into the first parallel port on that node, accessed as /dev/par1. On the sending_node, the same printer (this time known as rlpt1) is shown to be located on the remote machine called printing_node and, on that machine, the printer is known as lpt1.

The /etc/printcap file can contain a lot more information than this minimal set, you can use it to fully describe each printer connected on your network; you can also use it to change related information such as the default spooling directory the printer will use. See /etc/printcap in Utilities Reference for a full description of all the options at your disposal. See also, "Setting up /etc/printcap".

A way of preventing unauthorized access

Printing privileges are granted to a remote node by including its name in an approved list kept in the etc/hosts.lpd file on the printing_node. Optionally, you can enter the approved node name in another file that is used by several other processes for authorization processes (etc/hosts.equiv), but to keep things simple and minimal, we will use the file specifically intended for printing authorization.

In etc/hosts.lpd on the printing_node, add the following entry:

sending_node

The printer system maintains protected spooling areas so that users can't circumvent printer accounting or remove files other than their own. The strategy used to maintain protected spooling areas is as follows:

· Only the print manager daemon can spool print jobs.
 · Only root and the print manager daemon can read spooled print files.
 · Users cannot modify control files.
 · Users may alter files in the spool directory only via the print utilities.
 · The print manager authenticates all remote clients (the method used is similar to the authentication scheme explained in rshd in the Utilities Reference).
A network manager capable of delivering the files to be printed

The RTP network manager is io-net. This manager loads shared objects (DLLs) to provide the protocols and device drivers needed. We will follow the general guidelines for setting up a two-node network (see "Setting up a two-node Ethernet network"), except that, for this example, we will load only the tiny TCP/IP stack npm-ttcpip.so and a device driver suitable for NE-2000 compatible Ethernet adapters, devn-ne2000.so. Our io-net command line will look like this:

io-net -dne2000 -pttcpip

If you are using a TCP/IP stack like this, you might want to configure your network interface using the -if option of npm-tcpip.so or npm-ttcpip.so to specify the type and number of your NIC, and the IP address and netmask for your TCP/IP interface.

A method of organizing and preparing print jobs

RTP provides a print manager daemon to handle print jobs (see lpd in Utilities Reference. This daemon acts as a master server for coordinating and controlling the spooling queues configured in the /etc/printcap file. To start the print manager daemon, simply type:

lpd

When started, lpd makes a single pass through the /etc/printcap database, restarting any printers that have jobs waiting. In normal operation, lpd listens for service requests on a socket within the Internet domain (under the printer service specification) for requests for printer access. When it receives a print request, lpd spawns a copy of itself to process the request while the master daemon continues to listen for new requests.

To process the print job, the spawned lpd either schedules the job to be printed locally, or if printing remotely, attempts to forward the job to the appropriate machine. If the printer can't be opened or the destination machine can't be reached, the job remains queued until the work can be completed.

A user interface

When you have set up your remote printing network, you will be able to use the following print utilities to print files remotely and to find out and affect what is going on:
To do this:
 		Use this utility
Print a file
 		lpr
Examine a print spool
 		lprq
Remove a print job
 		lprrm
Control the system (root only)
 		lprc (also see "Line printer administration")

Printing your files

If you have set up your remote printing network according to the examples given, you should be able to print a sending_node file in /tmp/test on the printer attached to the printing_node using a command like this:

lpr -h -Prlpt1 /tmp/test

Here's what happens:

Remote printing to a printer on another network

Using TCP/IP and lpr, you can print a file on a remote printer connected to a server on another network. You just have to set up the RTP node for remote printing and the remote server for TCP/IP and handling lpr-compatible printers. E.g. suppose you want to print a PostScript file (/root/junk.ps) on a remote printer (named nt_printer) connected to an NT server (IP address 10.2.1.8), from a node on your RTP network; here's what you need to do:

On your NT server you have to configure a computer running Windows NT for TCP/IP printing and to create an LPR-compatible printer (both topics are covered in Windows NT Help).

As root, on your RTP node:

This sends a PostScript file to the remote printer named nt_printer connected to the NT server located at 10.2.1.8.

Remote printing to a TCP/IP-enabled printer using lpr

A TCP/IP-enabled printer does not need an attached computer to provide the print services we talked about in "Remote printing", these services are provided in the printer itself. So you use the same basic steps described in Remote printing, with the following minor alterations:

This example shows that the name of the remote machine (in this case, the actual printer) is tcpip_printer and the spool directory is /usr/spool/output/lpd/rlpt2. You'll notice that the remote printer is named as /ps: this is the name the network printer we use (a Lexmark Optra S2450) has for accepting PostScript files. You will need to find out the name your printer wants you to use; it may require different names for different types of print file format (e.g. PostScript and text files).

Make sure you have created your spool directory and that's about it. Follow the usual steps described in Remote printing and then you should be able to print to your remote printer using a command line like this: 

lpr -Prlpt2 /root/junk.ps

This sends a PostScript file to the remote printer named tcpip_printer located at the IP address 10.2.0.4.

To keep it simple, we've taken the easy way out in this example by sending a PostScript file to a PostScript printer. It's easy because the formatting is embedded in the PostScript text. You may have to get into print file filtering to get your printer to work using lpr; you specify the filter to be used in the printcap entry for the printer, See "Filters"

Remote printing to a TCP/IP-enabled printer using spooler

Printing to a remote printer using spooler is a bit tricky, but it can be done by piping the print job to lpr. You take advantage of the fact that the filter sends the print job to the printer; you just name the remote printer in the filter command line of the configuration file used by spooler.

To try it out, first get your remote printer working using lpr (see "Remote printing to a TCP/IP-enabled printer using lpr"); then do this:

Copy the configuration file from the printer you want to use (we'll say you want to use a PostScript printer to illustrate the process): 

cp /etc/printers/ps.cfg /etc/printers/test.cfg

Find the filter command lines in test.cfg; they look like this: 

Filter   =   phs:$d:phs-to-ps
Filter   =   raw:$d:cat

Change the phs filter command line from this: 

Filter  =   phs:$d:phs-to-ps

To this: 

Filter  =   phs:ps:phs-to-ps

Then add a line to tell the filter to send all PostScript files to the remote printer, rlpt2: 

Filter    ps:$d:lpr -Prlpt2

These filter command lines follow the source:destination:filter sequence. Before you changed it, the phs filter command line told the filter to process .phs files by sending them through a filter called phs-to-ps then to the destination passed by spooler; you changed the destination to ps, so after the phs file has been converted to a ps type, it goes to the ps filter. The ps filter line you added sends PostScript files to the lpr, forcing output to the remote printer (just as you did in "Remote printing to a TCP/IP-enabled printer using lpr").

Finally, slay the running spooler and then start a new one telling the spooler the pathname of your new config file (in this case /etc/printers/test.cfg) and the name of the printer you want to use (in this case rlpt2), like this: 

slay spooler
spooler -d /dev/null -c /etc/printers/test.cfg -n rlpt2 &

Now, you should be able to print your PostScript file on your remote TCP/IP-enabled printer, either from Photon or from the command line.

All Photon applications use spooler for printing, so to print remotely from ped, for instance, you just have to select the correct printer (in this example, rlpt2) in the Select Printer dialog box.
 Do the same thing as the Photon application by copying the print file to the fake directory used by spooler, like this:
 
cp /root/junk.ps /dev/printers/rlpt2/spool/junk.ps
Troubleshooting remote printing problems

If the file you send does not print, you may get an error message from one of the lp* print utilities: See "Understanding lpr error messages" If you don't get an error message, check the following:

Connecting terminals

[Author's Comments: (@@What do I need in a terminal? Do I need to know any hardware details before I start? How do I configure terminals? How do I find the terminal type?]
[Author's Comments: What are the environment variables? What is the terminal database? How do I use it?)]

[Author's Comments: @@explain stty And how it is used. Also, How do I set up a login process?]

Connecting other I/O Devices

Check out the list of supported hardware at the QNX supported hardware web site. For technical support options, see the QNX Support and Services we site.

Audio cards

[Author's Comments: (@@How do I configure audio cards?)]

CD-ROM

The cam-cdrom.so shared object provide a common access method for CD-ROM devices. For information on this shared object, see the Utilities Reference.

Console devices

[Author's Comments: new utility input-cfg makes this easy]

[Author's Comments: @@How do I configure a mouse on a terminal?)--check out ((@@add cross ref) xid="file:///usr/help/product/neutrino/utilities/d/devi-hirun.html">devi-hirun<)) --give examples]

[Author's Comments: (@@How can I setup mouse parameters (speed, wheel, change to left-handed etc...) ? Are wheelmice supported? --for ps/2 wheelmouse support, try installing: http://www.qnxstart.com/cgi-bin/download.cgi?file=wheeldrv -- it worked for me :-))]

DVD

[Author's Comments: (@@How do I handle DVD? What are DVD regions? What do they mean to me?--Movies are released on DVD at different times around the world. To preserve the movie release scheduling system, DVDs and DVD players are programmed with a code denoting one of six world regions; the idea is that DVDs purchased in one region will play only on DVD players from the same region. )]

[Author's Comments: see reportdvdregion and setdvdregion in UT -- note warning about latter]

Floppy disk

For information on mounting floppy disk drives, see "Using floppy disks".

Hard disk

[Author's Comments: (@@How do I configure hard disks? explain cam-disk.so)]

LS120

[Author's Comments: (@@How do I config it?]

LS-120 is a SuperDisk drive. These drives use new technology that greatly improves head alignment, enabling a much greater storage capacity (120 MB) than conventional 3.5-inch disks.

Orb

An Orb drive is a fast large-capacity removable storage disk drive that uses 3-1/2" storage media.

[Author's Comments: (@@How do I mount it?]
Zip and Jaz

Zip and Jaz disks are large-capacity removable storage disks used for backing up hard disks and for transporting large files.

[Author's Comments: (@@How do I mount it?]

Modems

[Author's Comments: include information on cable modems]

Pseudo terminals

[Author's Comments: (@@What are pseudo terminals?)]

Video cards

[Author's Comments: (@@How do I configure video cards? How do I change resolution and refresh rate?)]

QNX Software Systems Ltd.
http://www.qnx.com
Voice: +1 613 591 0931
Fax: +1 613 591 3579
info@qnx.com
TOC PREV NEXT INDEX