Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Software Flow Control #1547

Open
cptaffe opened this issue Dec 16, 2024 · 3 comments
Open

Software Flow Control #1547

cptaffe opened this issue Dec 16, 2024 · 3 comments

Comments

@cptaffe
Copy link

cptaffe commented Dec 16, 2024 •
edited
Loading

Currently, irssi intercepts software flow control XOFF signal ^S and prints S, which breaks software flow control.

Physical terminals like the VT220 send XOFF when in settings mode or after having received some fixed character sequence, and then XON after having processed that batch. The VT220 specifically expects XOFF to halt the flow of incoming characters, and if it receives an additional character it will send XOFF again -- since irssi treats ^S as S, this leads to an infinite loop which will stall commands like tmux attach if irssi is the active window (and forces a hard reset of the terminal) or leads to long sequences of S in the prompt after having entered and exited settings. Software flow control must be used if hardware flow control is unavailable.

A similar problem occurs over telnet when software flow control is in use.

As discussed on IRC, since irssi is single-threaded, XOFF may result in dropped connections. In practice, ^S/XOFF is usually sent to slow down the incoming flow of characters and is soon followed by ^Q/XON.
@mbbrutman
Copy link

The offending code is here ...

irssi/src/fe-text/terminfo-core.c

Line 513 in ee4471a

/* Disable the ICRNL flag to disambiguate ^J and Enter, also disable the

I know real terminals are not in widespread usage, but it's kind of bad to take over a key function (flow control) on a TTY based interface. And yes, I know it has been like this for years ...

@cptaffe
Copy link
Author

cptaffe commented Dec 16, 2024

Nei mentioned on IRC that they believe the average user expects to bind ^S or ^Q; if so, perhaps ^S and ^Q could be passed through only if unbound by the user. That way, by default software flow control would work, but the user still has the flexibility to assign these control sequences.

@cptaffe
Copy link
Author

cptaffe commented Dec 18, 2024

Not all terminals have xon_xoff enabled, and it's documented in terminfo for that terminal:

$ infocmp -L -1 vt220 | grep xon_xoff
	xon_xoff,
$ infocmp -L -1 xterm-256color | grep xon_xoff

Only respecting XON and XOFF if the current $TERMhas xon_xoff configured would further reduce the number of users affected, since we could respect XON/XOFF based on whether the terminal will ever send it.

It's also possible to configure terminfo with xoff_character and xon_character in case they are not the default control characters ^S and ^Q.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@cptaffe @mbbrutman