On Mon, 8 Nov 1999, Hauke Fath wrote:

> At 19:39 Uhr +0100 08.11.1999, Bill Studenmund wrote:
> >Yes, but as you've mentioned, it's hooked up to the dtr pin. ;-) _That's_
> >why it's cdtrcts.
> 
> No. It is HSKo, a general-purpose output line that is in no way tied to the
> SCCs internal state other than the corresponding register bit and for all
> we know could be the SCC RTS, its DTR or any line from a 6522 VIA.

Kinda. While that's what Apple calles it in pictures of the port, when
they talk about flow control modes, they call HSK? DTR and CTS. See:
http://developer.apple.com/techpubs/mac/Devices/Devices-315.html#HEADING315-24
which is in the serial driver docs for an example. Note: this example is
part of the reason we call it cdtrcts. :-)

Also, if you feed a DeskWriter at too high a data rate (ignore
handshaking), it complains about DTR handshaking overflows..

> >But the misconception is on the other programs' thinking that crtscts is
> >the only flow control form. From the point of view of the driver, the pin
> >in question is the DTR pin.
> 
> HSKo.  =8)

Nope. DTR. HSKo doesn't translate well into NetBSD. For instance, if you
use the TIOCMXXX ioctls, this pin is controlled by TIOCM_DTR. 

> Sorry to pick nits, but a (modem) cable that connects HSKo to DTR only is
> simply not going to give you hardware flow control for incoming data with
> any real-world modem. The modem will then either ignore what you feed it on
> pin 20, or it will control the line state depending on pin 20 -- which is
> DTR semantics.

Oh. This might explain a lot. I don't think anyone expects the other side
to do cdtrcts handshaking, unless it is another mac.

> You won't get hardware flow control until you bridge the modem's DTR and
> RTS (or wire RTS only), *and* tell the modem to ignore what happens on pin
> 20/DTR. At that moment, you give up line control and use HSKo with RTS
> semantics.
> 
> Repeat: To use the Mac's HSKo for controlling the flow of incoming data
> (RTS), you need to explicitly *remove* DTR semantics both on the Mac side
> (serial driver) *and* on the modem side (AT&D0 and change wiring).

Understood. But you're also talking about the cable explicitly doing a
wiring conversion... 

> No DTR left on both sides, sorry. Thus, no point in calling the mode "cdtrcts".

Uhm, it's still the DTR pin. It's not cdtrcts because we use DTR
semantics, but because we use the DTR pin.

> That is what I (strongly ;) feel is wrong and what I am proposing to change.

Well, I wasn't the one who came up with this solution. So I'm not the one
you need to convice, though I do agree with the decision. 

> >"has the right not to?" ??
> 
> A userland program has the right to depend on rtscts being called rtscts,
> not blafasel.

But from the point of view of the kernel, there is no (externally visable)
RTS pin, so what sense does crtscts make?

That's the whole point: from NetBSD's point of view, the serial port has
one output, DTR. Not HSKo, but DTR. We went with this partly because
that's how the hardware's laid out, and partly because that's how Apple's
serial driver refers to it. :-)

Take care,

Bill