[Toybox] microcom.c discarding data due to TCSAFLUSH

[Yi-Yo Chiang]

On Fri, May 24, 2024 at 12:11 AM Rob Landley <rob at landley.net> wrote:

> On 5/20/24 09:42, Yi-Yo Chiang via Toybox wrote:
> > Is there any particular reason to use TCSAFLUSH here?
>
> Partly because it's what strace said busybox and minicom were doing, and
> partly
> because I've had serial hardware that produced initial static on more than
> one
> occasion.
>
> In this case, it looks like Elliott also put it in his initial contribution
> (commit 12fcf08b5c96).
>
> > If not, can we change to TCSADRAIN or TCSANOW. I don't think there is
> good
> > reason to _discard received data_ just to set the terminal mode...? Is
> there
> > really a real world case that the device termios is so dirty that all
> data, from
> > before setting raw mode, must be discarded?
>
> I've seen multiple instances where there was initial noise from the port
> going
> live before the speed stabilized, or static from a physical connection
> plugging
> in or powering up, or truncated bootloader messages that filled up the
> input
> buffer then abruptly cut off.
>

Fair enough. But I think this kind of behavior would be better as a flag
option
-[f]lush -- flushes the terminal when initializing connection
or
-[r]esume -- resume existing connection, don't flush terminal
or a "flush/reset terminal" escape-menu command or a standalone shell
command like `reset`.
My point being, let the user decide how to handle noise / junk.
It's possible that the signal is already filtered, or useful signal are
mixed together with junk, no? (thus making the noisy "junk" useful for
people with a keen eye)


>
> > I also tried to modify the microcom code to skip tcsetattr() if the
> device
> > termios is already equal to the mode we are setting it.
> > `if (old_termios != new_termios) tcsetattr(new_termios, TCSAFLUSH)`
> > However this doesn't work because microcom always tries to set the
> device baud.
>
> Hmmm, you're right, it shouldn't mess with that unless we specify -s. I
> could
> also make TCSAFLUSH only happen when we do -s (because otherwise it's an
> existing connection and we're not messing with it, but I still need to
> make sure
> it's in raw mode)...
>
> Note: FLAG(s)*TCSAFLUSH becomes 0 (TCSANOW) in the absence of -s.
>
> > For example a pty device might be configured to use buad 38400,
>
> Why set the baud at all on a pty? A pseudo-terminal doesn't have a baud
> rate,
> leave it alone. (You can also inherit a serial port that was set up by the
> bootloader and should again just be left alone...)
>

I didn't set the baud to 38400, it's the default value of my Linux kernel.
As far as I understand, even if pty does nothing with the baud, it still
assigns some _sensible_ number to it. To make it look more like a physical
tty.
I don't know why it's doing this, maybe to maintain some sort of existing
contract?


>
> > but microcom
> > would want it to be 115200, thus flushing it's data. but pty doesn't
> really care
> > about the baud most of the time AFAIK, so flushing data in this case
> just seems
> > disruptive to the user experience.
>
> Setting baud rate and flushing are two different switches in the
> interface, but
> in this case flushing only when setting the baud rate seems a good use of
> the
> existing controls.
>
> Try commit 2043855a4bd5
>

Works nicely. Thanks!


>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240524/2e5f2cc9/attachment.htm>