This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: tty.c driver bug?
- To: ecos-discuss at sourceware dot cygnus dot com
- Subject: Re: [ECOS] tty.c driver bug?
- From: Jonathan Larmour <jlarmour at redhat dot co dot uk>
- Date: Wed, 05 Apr 2000 20:04:05 +0100
- Organization: Red Hat UK Ltd.
- References: <Pine.BSF.4.10.10002020855400.4675-100000@plasticgrape.com>
Prompted by Sergei's recent bug report, I don't recall this mail from
Patrick being resolved. Is that right?
I believe Patrick's analysis is correct, and the code still appears to be
the same, but I want to check that this wasn't resolved some other way
before I fix.
Jifl
Patrick O'Grady wrote:
>
> Hi, All--
>
> Hmm... sounds like we're all in sync, looking around at the serial port
> drivers! I think that I've found another bug--tell me what you think. The
> page
> http://sourceware.cygnus.com/ecos/docs-latest/ref/ecos-ref/tty-driver.html
> shows some of the different TTY input and output modes which can be
> selected... it implies that CYG_TTY_IN_FLAGS_CR will translate '\r' into
> '\n', and that CYG_TTY_IN_FLAGS_CRLF will translate the pair '\r\n' into a
> single '\n'... however, looking in
> packages/io/serial/current/src/common/tty.c, about line 212, shows that
> CYG_TTY_IN_FLAGS_CR is ignored, and that CYG_TTY_IN_FLAGS_CRLF will
> generate a pair of '\n':
>
> (Code snip:)
>
> ...
> } else if ((c == '\n') || (c == '\r')) {
> clen = 2;
> if (priv->dev_info.tty_in_flags & CYG_TTY_IN_FLAGS_ECHO) {
> cyg_io_write(chan, "\n\r", &clen);
> }
> if (priv->dev_info.tty_in_flags & CYG_TTY_IN_FLAGS_CRLF) {
> c = '\n'; // Map CR -> LF
> }
> buf[size-1] = c;
> break;
> }
> ...
>
> Looks like CYG_TTY_IN_FLAGS_CRLF should really be CYG_TTY_IN_FLAGS_CR, and
> that a previous character should be stored for use with
> CYG_TTY_IN_FLAGS_CRLF. I'll use CYG_TTY_IN_FLAGS_CRLF for the time
> being--all I really care about is when the user presses '\r'. Might be a
> good idea that CYG_TTY_IN_FLAGS_CRLF returns a single '\n' for either
> '\r\n' or '\n\r'... I've seen some lame systems which output those
> characters in reverse. Cheers!
>
> -patrick
>
> patrick@softprocess.com
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault