Why Is It So Hard to Detect Keyup Events on Linux?

Re:Why Is It So Hard to Detect Keyup Events on Linux? by zozbot123 on Sunday January 27, 2019 @01:29PM (#19012989)

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.

[ Parent | on HN ]

Re:Why Is It So Hard to Detect Keyup Events on Linux? by cryptonector on Sunday January 27, 2019 @01:37PM (#19013037)

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.

[ Parent | on HN ]

Re:Why Is It So Hard to Detect Keyup Events on Linux? by zozbot123 on Sunday January 27, 2019 @01:55PM (#19013134)

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

[ Parent | on HN ]

Re:Why Is It So Hard to Detect Keyup Events on Linux? by 0x0 on Sunday January 27, 2019 @03:27PM (#19013594)

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

[ Parent | on HN ]

Re:Why Is It So Hard to Detect Keyup Events on Linux? by cryptonector on Sunday January 27, 2019 @03:16PM (#19013545)

You are absolutely right. Are there any such features that produce additional in-band data for every keystroke?

[ Parent | on HN ]

Re:Why Is It So Hard to Detect Keyup Events on Linux? by caf on Sunday January 27, 2019 @09:37PM (#19015050)

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?

[ Parent | on HN ]