On Fri, May 24, 2024 at 12:11 AM Rob Landley <r...@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 >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
