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

If, in the late 70s, key up events in tty context had been important, then terminal vendors would have developed an escape sequence system for expressing those. But it wasn't, so they didn't.

So, yes, it's absolutely impossible to get key up events in tty context, and at this point it will almost certainly stay that way forever, as it's too late to retrofit terminal emulators, drivers, and applications to understand whatever protocol for communicating key up events. (The right way to do this would be to develop an escape sequence protocol that the tty/pty drivers could decode and turn events into out-of-band events to be delivered via ioctl()s, that way applications that don't care about key up events don't see them and don't need to be modified. But who is going to do all that work?)

In any case, the stated goal "to remotely navigate a robot over an SSH connection using the 'w', 'a', 's', 'd' keys" is misguided to begin with; what happens when your connection drops and the robot can't be stopped?

Addendum: has the author thought about the case where the user is using a keyboard layout where the WASD keys are not together, or where the user is using a non-latin-alphabet keyboard? As someone who uses a dvorak-based layout, I am annoyed at how often developers screw the key/character distinction up and assume everyone uses qwerty.

EDIT: I’d also like to mention that “Linux” has nothing to do with this. One would face the same issues using a Windows SSH client connecting to a Solaris SSH server.

That said, is there a more end-to-end summary out there of how keyboard input is handled in GNU/Linux? I have the vague understanding that USB HID scancodes are translated into keycodes, which are sent along to X applications or a TTY, but where and how each step happens is still a bit mysterious to me.

INPUT_RECORD https://docs.microsoft.com/en-us/windows/console/input-recor...

KEY_EVENT_RECORD https://docs.microsoft.com/en-us/windows/console/key-event-r...

    bKeyDown
    If the key is pressed, this member is TRUE. Otherwise, this member is FALSE (the key is released).

I'll again have to criticize this submission's title. It shouldn't be " Why Is It So Hard to Detect Keyup Event on Linux?" (it's not a problem with the kernel), it should be something along the lines of "Why can't I detect key up events via SSH?".

And the answer to that is simple: That's not what it's designed for.

Or, even better: Instead of concentrating on the complaints part of the article provide on the part in which you're providing value to your readers: "Detecting keyboard events without a display server" or, if you want to get in on the long headlines trend: "Detecting key up events in a TTY environments is hard. Here are some ways".

Traditionally under the CLI you will manage key input wih a readline() command or something similar to kbhit() and depending on your needs you'll use getchar() then track if either a CR or LF is entered for the "end of command", also EOF.

This is blocking, so nothing else can happen, and depending on how you do it, you can only read single byte chars and not mutlibyte chars (like CJK input)

something like

    while( run )
    {
        i=kbhit();

        if( i != 0 )
        {
            key = String.fromCharCode( getchar() );

            if( (key == "\n") || (key == "\r") )
            {
                run = false;
            }
            else
            {
                buffer += key;
            }

            i = 0;
        }
    }

    while( run )
    {
        b = fgetc( stdin );

        if( b == EOF )
        {
            if( kbuffer.length == 0 )
            {
                return null;
            }

            run = false;
        }
        else if( b == LF )
        {
            run = false;
        }
        else
        {
            kbuffer.writeByte( b );
        }
    }

now because Redtamarin is based on AVM2 and AS3, there is one part of the API which try to reimplement the Flash API with such things like KeyboardEvent that should be able to be non-blocking but still for a CLI environment

That KeyboardEvent should detect keyUp or keyDown but yeah it is hard to detect and if you try to do that for multipel platforms liek Windows / macOS / Linux it gets nigthmarish

In a little experiment [1] I found out you can do "stupid things" that actually work, like spawning a child worker (AVM2 uses pthread), blocking on the user input (like above) and then send back a message to your main worker and so receive a "key event", all that allow to listen for input asynchronously

But then, what about making the difference between keyUp and keyDown ? I decided to ignore the keyUp because in fact it does not really matters on the CLI or I least I don't see any use to it, for a GUI yes I can see the use cases, but for a CLI? not so much

Purely on the CLI (no X Server) you don't really listen for key events you read the stdin stream, the only special events are signals like SIGINT SIGHUP etc. or special kind of signals like EOF.

The other things you can alterate is the buffering of that stdin and the raw mode/cooked mode and echo off/on.

So for a use case like navigating something using the 'w', 'a', 's', 'd' keys you just need to go async to listen for chars input (which key is pressed) and probably a mix of timeout on the last key pressed and a "diff" between the "prev key" and "last key".

If last key pressed is 'w' then go up, if you keep receiving a 'w' key you keep going up, if prev key was 'w' and the last key is different you change direction.

And to detect when to stop to go up if last key pressed was 'w' you just keep the time when this key was pressed, if 1 second elapsed and no more key events are received you stop going up, ergo you don't need to detect keyUp, but maybe I'm missing something.

  [0]: https://github.com/Corsaair/redtamarin
  [1]: https://twitter.com/redtamarin/status/900794336031510530

I grew up in the waterfall (as opposed to agile) era of the 80s and 90s. Back then, it was top priority to catch mistakes as early in development as possible. This is the top article I could find on the concept, which seems to stir a lot of debate:

https://developers.slashdot.org/story/03/10/21/0141215/softw...

The gist of it is that if a bug costs $1 to fix during development, it costs $10 to fix during testing and $100 to fix once it's in production. Maybe someone can find the original quote.

Had I been working on terminals in the 70s, I would have been the annoying person in the back of the room who raised their hand and said "what about key ups?" There would have been a lot of muttering, much debate about how to store keymap bit arrays and what might happen if they get out of sync, every edge case would be explored, and in the end my opinion would be noted somewhere and character streams would have moved forward as the "simpler" implementation.

But it's not simpler, because perfectly valid use cases were excluded. Basically, their decision meant that we couldn't have video games in the terminal. Kind of a big deal, if you ask me.

After so many decades of this, it's hard for me to drink the Kool-Aid on new frameworks, even if they're ones we use every day like C++ (operator overloading was maybe a bad idea in hindsight), git (can't store folders without .gitkeep), Angular (two way binding - oops), React (front end PHP), even HTML/CSS/Javascript (difficulty encoding our own tags as components/nondetermistic inheritance across browsers/mutability). These frameworks are great, but it takes a certain level of suspension of disbelief to buy into them.

Give me 5 minutes with any technology and I'll find the conceptual flaws and bugs that impose major hurdles on its conceptual simplicity, utility and reusability. Basically everything I touch breaks. It's like a knack that makes me a good programmer, but also a Debbie Downer.

https://www.youtube.com/watch?v=MZF6EK7x4Dk

P.S. The workaround for the keyup thing is probably to set the key repeat threshold and repeat delays to 0 and check for repeated keydown events each main loop, setting the keymap entry to true if the key is still down (false otherwise). It's not perfect because it can't easily detect multiple keys down or modifier keys, but that was one of the ways we did it in classic Mac OS anyway.