> DTR/DSR is a very often used handshake for serial printers, at least> in the POS field. A lot of supermarket cash registers are in fact PCs> with special hardware, which for some unclear reason typically knows> only about DTR/DSR handshaking (even if it is from other vendors:> SNI or EPSON does not make a difference: only DTR/DSR).> > Sending people to a thousand stores around the country putting special> cables between printers and computers is simply not acceptable (if you> know POS service people, you know that about half of the cables would> be put on the wrong serial ports).> > This patch is very small and you should be able to easily see any side> effects it might have.> Yes, I'll second this. I get requests for DTR/DSR (and DTR/CD) hardwareflow control in Kermit all the time for this kind of reason. The equipmentinvolved is not "legacy" (my least favorite word -- in common parlance itmeans "not Microsoft") at all, just weird.

There are standard APIs in SVR4 for all sorts of hardware flow control,specified in <termiox.h> (or <sys/termiox.h>):

ioctl(fd,command,arg)struct termiox * arg;

The termiox struct contains a member:

unsigned short x_hflag; /* hardware flow control modes */Which can be set to various combinations of:

TCGETX - get termiox params into arg.TCSETX - set termiox params from arg immediately.TCSETXW - ditto, but waits til after output queue is finished.TCSETXF - like TCSETXW but also discards all chars queued for input.

I'll be glad to supply greater detail from the SVID if needed.

- Frank

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/