3 ms·

This is somewhat overstated. Unix-like systems have a whole framework of "termcap" and "terminfo" descriptions of terminal capabilities, and it wouldn't take mu

This is somewhat overstated. Unix-like systems have a whole framework of "termcap" and "terminfo" descriptions of terminal capabilities, and it wouldn't take much to add a keyup-reporting mechanism to these that's shared between e.g. xterm, the Linux VGA console and the modern Linux FB-console. This is similar to how "terminals" have been retrofitted to enable, e.g. mouse support, or 256-color support, or viewport-size reporting.

cryptonector 8y ago
Yes, but termcap/terminfo are about output, not input. Some output sequences could be used to alter terminal behavior, of course, but if no terminals implemented a protocol for sending key up events, then that wasn't going to get implemented. Recall that termcap/terminfo are about abstracting differences in terminals, not about driving terminal evolution. And again, any in-band protocols for sending metadata like key up events would have required much more than merely a terminal capability abstraction layer like termcap or terminfo: it would have required something like a variant on tty/pty driver raw mode so that legacy applications need not be modified to understand this. Or, alternatively, it would have required shells at minimum to understand these new modes so that they could still let you type `tputs ...` to recover from apps putting the terminal into that mode but not restoring the terminal to its previous mode upon death/stop.
- zozbot123 8y ago
  > Yes, but termcap/terminfo are about output, not input. Termcap itself--the older system of the two, and the one that's mostly subsumed by terminfo nowadays--supports input-related features already! See e.g. https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html#SEC37 https://www.gnu.org/software/termutils/manual/termcap-1.3/ht... Anyway, surely some sort of keyboard raw input exists already, if only so that X can use it? AIUI, X does run without root privileges these days, and keyboard input was never the main obstacle to X running without root - video output was. So, I think the article is not quite right in its assumption that detecting raw keyboard events necessarily involves root-level access.
  - cryptonector 8y ago
    You are absolutely right. Are there any such features that produce additional in-band data for every keystroke?
  - 0x0 8y ago
    Looks like non-root X still requires the equivalent of root access to the raw input /dev devices - https://wiki.gentoo.org/wiki/Non_root_Xorg#Making_necessary_changes_to_system https://wiki.gentoo.org/wiki/Non_root_Xorg#Making_necessary_...
- caf 8y ago
  Or, alternatively, it would have required shells at minimum to understand these new modes so that they could still let you type `tputs ...` to recover from apps putting the terminal into that mode but not restoring the terminal to its previous mode upon death/stop. This subtlety is the crux of the issue. There's already precedent for input features that the program can opt-in to using output escape codes, like bracketed paste mode. But these don't change input so radically that they'd stop you from using your shell if the terminal was left in that mode after a program crash. Maybe you could make it work by saying that key state event mode is automatically disabled after every newline from the terminal and the program needs to explicitly re-enable it?

cryptonector 8y ago

Yes, but termcap/terminfo are about output, not input. Some output sequences could be used to alter terminal behavior, of course, but if no terminals implemented a protocol for sending key up events, then that wasn't going to get implemented. Recall that termcap/terminfo are about abstracting differences in terminals, not about driving terminal evolution. And again, any in-band protocols for sending metadata like key up events would have required much more than merely a terminal capability abstraction layer like termcap or terminfo: it would have required something like a variant on tty/pty driver raw mode so that legacy applications need not be modified to understand this. Or, alternatively, it would have required shells at minimum to understand these new modes so that they could still let you type `tputs ...` to recover from apps putting the terminal into that mode but not restoring the terminal to its previous mode upon death/stop.

zozbot123 8y ago
> Yes, but termcap/terminfo are about output, not input. Termcap itself--the older system of the two, and the one that's mostly subsumed by terminfo nowadays--supports input-related features already! See e.g. https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html#SEC37 https://www.gnu.org/software/termutils/manual/termcap-1.3/ht... Anyway, surely some sort of keyboard raw input exists already, if only so that X can use it? AIUI, X does run without root privileges these days, and keyboard input was never the main obstacle to X running without root - video output was. So, I think the article is not quite right in its assumption that detecting raw keyboard events necessarily involves root-level access.
- cryptonector 8y ago
  You are absolutely right. Are there any such features that produce additional in-band data for every keystroke?
- 0x0 8y ago
  Looks like non-root X still requires the equivalent of root access to the raw input /dev devices - https://wiki.gentoo.org/wiki/Non_root_Xorg#Making_necessary_changes_to_system https://wiki.gentoo.org/wiki/Non_root_Xorg#Making_necessary_...
caf 8y ago
Or, alternatively, it would have required shells at minimum to understand these new modes so that they could still let you type `tputs ...` to recover from apps putting the terminal into that mode but not restoring the terminal to its previous mode upon death/stop. This subtlety is the crux of the issue. There's already precedent for input features that the program can opt-in to using output escape codes, like bracketed paste mode. But these don't change input so radically that they'd stop you from using your shell if the terminal was left in that mode after a program crash. Maybe you could make it work by saying that key state event mode is automatically disabled after every newline from the terminal and the program needs to explicitly re-enable it?