[Toybox] microcom.c discarding data due to TCSAFLUSH

[Rob Landley]

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.

> 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...)

> 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

Rob