8 ms·

I mean, that there's no key up event in tty context goes back to the beginning of time, and is not Linux's fault, and not even Unix's (nor VMS's) fault, or anyo

I mean, that there's no key up event in tty context goes back to the beginning of time, and is not Linux's fault, and not even Unix's (nor VMS's) fault, or anyone's fault, because this all works the way it does because of how terminals worked, and they worked the way they did because it was simple. 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?)

gameswithgo 8y ago
this kind of highlights one of the differences between FOSS and paid software. “not our fault” “too late to fix it” versus a manager forcing you to fix the damn problem nobody cares whose fault it is. of course this difference is not innate, just a tendency.
- jstimpfle 8y ago
  Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. The Windows guys didn't care to fix this problem in a long long time. While Unix/FOSS platforms have traditionally been very strong in developers tooling. If you look in Windows more generally, they seem to be more wary not to break compatibility than Linux. That's because they need to run ancient programs that cannot be recompiled. I would say that "too late to fix it" is actually a problem with proprietary software, not FOSS.
  - thfuran 8y ago
    Developers deciding to develop good developer tooling on a FOSS platform is about the least surprising possible outcome and doesn't really seem to have much to do with whether FOSS or enterprise is better suited to fixing a big, uninteresting problem.
  - banachtarski 8y ago
    This isn't a super fair characterization. Visual Studio is miles ahead of Xcode or anything available on Linux as far as debuggers are concerned. You also have Windows Subsystem for Linux if you need it. Just because it doesn't conform to your particular workflow doesn't mean the development environment is a "mess." Personally I'm more productive in Linux for certain kinds of work, and more productive in Windows for other things (graphics work mainly, as the driver situation for GPUs on Linux is a "mess" to use your words).
    - jstimpfle 8y ago
      Yes, Visual Studio has a reputation for having the best in class debugger. While I don't know any graphical debugger for Linux that I would prefer to gdb. Other than that, Visual Studio has a reputation for being a morass slow POS. (Apparently that has gotten a little better with the latest releases). The game developers I follow all use Visual Studio exclusively for debugging. Otherwise they use a standalone editor and hand picked tooling, and batch scripts and the command window (or something like mintty which has its own problems) while cursing all the time.
      - banachtarski 8y ago
        > The game developers I follow all use Visual Studio exclusively for debugging. I work with all sorts of people in the industry across genres and I've seen plenty of workflows at many studios. I have no idea where you are getting this but you don't have any idea what you're talking about.
        jstimpfle 8y ago
- darkpuma 8y ago
  There is a long history of commercial UNIX... All have the same limitation. FOSS really has nothing to do with it.
- cryptonector 8y ago
  Eh? No, no one can fix this. Oracle couldn't fix this in Solaris. Microsoft can't fix this either (in Windows, in Linux, not at all). It's not a question of money, or managerial will-power. You're asking to boil a great lake, and if you have the money for it, you will almost certainly find better uses for it. There is no market demand for a "fix" here, so there cannot be any managerial will-power either. Nor is this due to Unix being open source back in the 70s, because it simply wasn't open source (and save for the erstwhile OpenSolaris, it still isn't). It wasn't entirely a research vehicle either, as AT&T used Unix as the OS for its phone switches. VMS too could not have had this feature, and for the same reasons -- though I'm not familiar enough with VMS, I feel absolutely certain that VMS did not have this either. And the hardware terminals (they were all hardware terminals back then, as there were no graphical terminals in which to emulate a terminal) were decidedly not open-source, and their vendors were in it for the profit. This, and all the wonky, hacky things to do with terminals, goes back to the way things were almost half a century ago, long long before "FOSS" even came to be. Software business models have absolutely nothing to do with why you can't have key up events in ttys. EDIT: And incidentally, windowing systems happened on the scene around 1984-1985. By 1987 even SVR2 had a windowing system in the AT&T Unix PC. But it was too late to retrofit key up events into ttys -- already by then there was over a decade of legacy, and hardware terminals continued to be a thing for some time yet. This is a crucial lesson in engineering: even relatively small amounts of legacy have profound effects on what is feasible, so often you have to get things right in the very beginning (precisely when it's hardest to get things right!).
  - ironmagma 8y ago
    There's a left out qualification here: "without breaking backwards compatibility". Sure, you can fix it, you just might have to change the entire stack a little bit and say goodbye to running all the programs currently out there. And then you can have a subsystem for backwards-compatibility, or in the worst case, a VM.
    - cryptonector 8y ago
      There is a ton of value in legacy. Maintaining backwards compatibility is a big deal. At some point you end-of-life a feature, but you generally don't want to make breaking changes. The tty is probably going to be with us for many more years yet (decades), so I don't see it getting end-of-lifed.
- guenthert 8y ago
  Uh and in commercial software you end up with a clutter of inane features, just because at one time a (potential) customer who seemed important requested it.
  - reaperducer 8y ago
    Providing features that users want. So terrible.
- 1023bytes 8y ago
  So is this possible in PowerShell? I don't think so
  - AnIdiotOnTheNet 8y ago
    Actually it totally is. Because PowerShell is not a tty. https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.host.pshostrawuserinterface.readkey?view=powershellsdk-1.1.0#System_Management_Automation_Host_PSHostRawUserInterface_ReadKey_System_Management_Automation_Host_ReadKeyOptions_ https://docs.microsoft.com/en-us/dotnet/api/system.managemen...
- tialaramex 8y ago
  It kind of does. The "paid software" will probably have some half-arsed attempt to "fix the damn problem" that makes everything awful, because a manager wasn't interested in hearing about "whose fault it is". It won't work properly, and you'll constantly be screwed over by it, but hooray, you've got "paid software" which your boss knows was able to "fix the damn problem" so there's no point even saying it can't be done, even though it can't be done - after all they paid good money, and whoever heard of a manager spending good money on a product that doesn't work... Most of you have probably used software built to this philosophy, a lot of the middle boxes for example. Most anti-virus software. Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it...
  - vardump 8y ago
    > Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it... Some of those products actually worked. They compressed RAM instead of paging it to disk. Which was a net benefit back then, and often still is. Similar techniques are in use in modern Windows, macOS and Linux.
  - izacus 8y ago
    > Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Those RAM doublers fixed the "damn problem" so well, that the implementation of them now lives in Linux AND macOS kernel and is enabled by default on all Macs, Android phones and several other devices. So I think the "fix the damn problems" mentality actually works.
- asveikau 8y ago
  What are you talking about? "We can't fix this bug, it's not our fault, too late" is all that Microsoft, Google and Apple ever say.
- reificator 8y ago
  > versus a manager forcing you to fix the damn problem nobody cares whose fault it is. All I'll say on this matter is that I find your views surprising, and we'll leave it at that...
- jchw 8y ago
  How does this relate to FOSS? Actually, is there even demand for this to be fixed at all?
  - msla 8y ago
    > How does this relate to FOSS? Anything relates to FOSS if it gets people riled up and makes the thread longer.
- GuB-42 8y ago
  There are lots of things Windows didn't fix in the name of backwards compatibility. And that part of what made it so successful. It is not a difference between FOSS and paid software but more about context: is fixing more important than consistency? Most FOSS is actually written by paid programmers, with grumpy managers who want that impossible problem to get fixed. If anything, the issue is that it is not always pushed back in the main line, sometimes for good reasons.
- michaelmrose 8y ago
  It's not impossible to fix it because its FOSS its impossible to fix it because nobody cares to invest a substantial amount of resources which is a separate but often entangled issue. It can also be too late to fix something in a deployed system because the resources required exceed the benefit derived in which case there will be no manager forcing anyone to fix anything.
draw_down 8y ago
This is such a strange reply, talking about whose fault it isn’t. Nobody is asking whose fault it is
zozbot123 8y ago
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.
Asooka 8y ago
But we did get mouse events in the terminal and certainly those didn't exist back in the 70s. Or bracketed paste. It's not hard to imagine that there will be a standard developed (well, 5 standards, then 15 standards and eventually one will remain as the de-facto standard) for keyup events, if there was demand for it.
ori_b 8y ago
> 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. Why would that be? It seems like it would just be a matter of adding another termcap entry for your specific terminal emulator, and hoping other people care enough to start implementing it in theirs. There's already no particularly consistent standard for most terminal events -- just a database of (I think turing-complete) stack VMs that tell programs how to parse whatever they read from the terminal emulator they're running under. Adding another string-named property to this table that describes key-up events would not be overly difficult.
- abcdef123xyz123 8y ago
  Hi > There's already no particularly consistent standard for most terminal events This is not really true anymore, almost all terminals still in use (and certainly all that are widely used) are VT100 compatible. In fact most are broadly compatible with xterm. So that is pretty much the standard now, and most new features being added to terminals don't take any account of other types of terminal at all. > It seems like it would just be a matter of adding another termcap entry for your specific terminal emulator, and hoping other people care enough to start implementing it in theirs. termcap was superseded by terminfo around the late 80s. A few applications still use it, but most are now terminfo. The termcap database on most systems is now derived from terminfo. terminfo is centrally managed as part of ncurses and stuff doesn't really get added to it just to see. The way it usually works is that one or more terminals add a feature and if it makes sense and is popular, applications will use it, and if applications use it then often it will end up in terminfo entries. Definitely if ncurses uses it, possibly if not (this can be controversial). You are right that there is no real reason a terminal couldn't send an escape sequence for key up, although it would certainly have to be something requested by the application - there are plenty of other escape sequences like that (eg the mouse, focus events). The tty doesn't really come into it, nor does the kernel or drivers, except for its own console terminal, but not many people use that very much. SGR mouse mode is an example of a terminal feature added relatively recently which has been taken up widely.
abcdef123xyz123 8y ago
> So, yes, it's absolutely impossible to get key up events in tty context There is absolutely no reason that many terminal emulators couldn't translate key up events into an escape sequence and forward them on to the application. So long as they receive them somehow themselves (eg an X terminal emulator will be told of them by X). It doesn't need to be out-of-band and it doesn't need to involve the tty driver. The right way to do it is to make them only sent when the application requests them. For example, this is how focus events work. If the application requests them with SM ?1004, \033[I is sent when the window gains focus and \033[O when the window loses it. There are not a lot of applications that use them, but some can (eg vim).

I mean, that there's no key up event in tty context goes back to the beginning of time, and is not Linux's fault, and not even Unix's (nor VMS's) fault, or anyo

gameswithgo 8y ago

this kind of highlights one of the differences between FOSS and paid software. “not our fault” “too late to fix it” versus a manager forcing you to fix the damn problem nobody cares whose fault it is. of course this difference is not innate, just a tendency.

jstimpfle 8y ago
Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. The Windows guys didn't care to fix this problem in a long long time. While Unix/FOSS platforms have traditionally been very strong in developers tooling. If you look in Windows more generally, they seem to be more wary not to break compatibility than Linux. That's because they need to run ancient programs that cannot be recompiled. I would say that "too late to fix it" is actually a problem with proprietary software, not FOSS.
- thfuran 8y ago
  Developers deciding to develop good developer tooling on a FOSS platform is about the least surprising possible outcome and doesn't really seem to have much to do with whether FOSS or enterprise is better suited to fixing a big, uninteresting problem.
- banachtarski 8y ago
  This isn't a super fair characterization. Visual Studio is miles ahead of Xcode or anything available on Linux as far as debuggers are concerned. You also have Windows Subsystem for Linux if you need it. Just because it doesn't conform to your particular workflow doesn't mean the development environment is a "mess." Personally I'm more productive in Linux for certain kinds of work, and more productive in Windows for other things (graphics work mainly, as the driver situation for GPUs on Linux is a "mess" to use your words).
  - jstimpfle 8y ago
    Yes, Visual Studio has a reputation for having the best in class debugger. While I don't know any graphical debugger for Linux that I would prefer to gdb. Other than that, Visual Studio has a reputation for being a morass slow POS. (Apparently that has gotten a little better with the latest releases). The game developers I follow all use Visual Studio exclusively for debugging. Otherwise they use a standalone editor and hand picked tooling, and batch scripts and the command window (or something like mintty which has its own problems) while cursing all the time.
    - banachtarski 8y ago
      > The game developers I follow all use Visual Studio exclusively for debugging. I work with all sorts of people in the industry across genres and I've seen plenty of workflows at many studios. I have no idea where you are getting this but you don't have any idea what you're talking about.
      - jstimpfle 8y ago
darkpuma 8y ago
There is a long history of commercial UNIX... All have the same limitation. FOSS really has nothing to do with it.
cryptonector 8y ago
Eh? No, no one can fix this. Oracle couldn't fix this in Solaris. Microsoft can't fix this either (in Windows, in Linux, not at all). It's not a question of money, or managerial will-power. You're asking to boil a great lake, and if you have the money for it, you will almost certainly find better uses for it. There is no market demand for a "fix" here, so there cannot be any managerial will-power either. Nor is this due to Unix being open source back in the 70s, because it simply wasn't open source (and save for the erstwhile OpenSolaris, it still isn't). It wasn't entirely a research vehicle either, as AT&T used Unix as the OS for its phone switches. VMS too could not have had this feature, and for the same reasons -- though I'm not familiar enough with VMS, I feel absolutely certain that VMS did not have this either. And the hardware terminals (they were all hardware terminals back then, as there were no graphical terminals in which to emulate a terminal) were decidedly not open-source, and their vendors were in it for the profit. This, and all the wonky, hacky things to do with terminals, goes back to the way things were almost half a century ago, long long before "FOSS" even came to be. Software business models have absolutely nothing to do with why you can't have key up events in ttys. EDIT: And incidentally, windowing systems happened on the scene around 1984-1985. By 1987 even SVR2 had a windowing system in the AT&T Unix PC. But it was too late to retrofit key up events into ttys -- already by then there was over a decade of legacy, and hardware terminals continued to be a thing for some time yet. This is a crucial lesson in engineering: even relatively small amounts of legacy have profound effects on what is feasible, so often you have to get things right in the very beginning (precisely when it's hardest to get things right!).
- ironmagma 8y ago
  There's a left out qualification here: "without breaking backwards compatibility". Sure, you can fix it, you just might have to change the entire stack a little bit and say goodbye to running all the programs currently out there. And then you can have a subsystem for backwards-compatibility, or in the worst case, a VM.
  - cryptonector 8y ago
    There is a ton of value in legacy. Maintaining backwards compatibility is a big deal. At some point you end-of-life a feature, but you generally don't want to make breaking changes. The tty is probably going to be with us for many more years yet (decades), so I don't see it getting end-of-lifed.
guenthert 8y ago
Uh and in commercial software you end up with a clutter of inane features, just because at one time a (potential) customer who seemed important requested it.
- reaperducer 8y ago
  Providing features that users want. So terrible.
1023bytes 8y ago
So is this possible in PowerShell? I don't think so
- AnIdiotOnTheNet 8y ago
  Actually it totally is. Because PowerShell is not a tty. https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.host.pshostrawuserinterface.readkey?view=powershellsdk-1.1.0#System_Management_Automation_Host_PSHostRawUserInterface_ReadKey_System_Management_Automation_Host_ReadKeyOptions_ https://docs.microsoft.com/en-us/dotnet/api/system.managemen...
tialaramex 8y ago
It kind of does. The "paid software" will probably have some half-arsed attempt to "fix the damn problem" that makes everything awful, because a manager wasn't interested in hearing about "whose fault it is". It won't work properly, and you'll constantly be screwed over by it, but hooray, you've got "paid software" which your boss knows was able to "fix the damn problem" so there's no point even saying it can't be done, even though it can't be done - after all they paid good money, and whoever heard of a manager spending good money on a product that doesn't work... Most of you have probably used software built to this philosophy, a lot of the middle boxes for example. Most anti-virus software. Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it...
- vardump 8y ago
  > Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it... Some of those products actually worked. They compressed RAM instead of paging it to disk. Which was a net benefit back then, and often still is. Similar techniques are in use in modern Windows, macOS and Linux.
- izacus 8y ago
  > Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Those RAM doublers fixed the "damn problem" so well, that the implementation of them now lives in Linux AND macOS kernel and is enabled by default on all Macs, Android phones and several other devices. So I think the "fix the damn problems" mentality actually works.
asveikau 8y ago
What are you talking about? "We can't fix this bug, it's not our fault, too late" is all that Microsoft, Google and Apple ever say.
reificator 8y ago
> versus a manager forcing you to fix the damn problem nobody cares whose fault it is. All I'll say on this matter is that I find your views surprising, and we'll leave it at that...
jchw 8y ago
How does this relate to FOSS? Actually, is there even demand for this to be fixed at all?
- msla 8y ago
  > How does this relate to FOSS? Anything relates to FOSS if it gets people riled up and makes the thread longer.
GuB-42 8y ago
There are lots of things Windows didn't fix in the name of backwards compatibility. And that part of what made it so successful. It is not a difference between FOSS and paid software but more about context: is fixing more important than consistency? Most FOSS is actually written by paid programmers, with grumpy managers who want that impossible problem to get fixed. If anything, the issue is that it is not always pushed back in the main line, sometimes for good reasons.
michaelmrose 8y ago
It's not impossible to fix it because its FOSS its impossible to fix it because nobody cares to invest a substantial amount of resources which is a separate but often entangled issue. It can also be too late to fix something in a deployed system because the resources required exceed the benefit derived in which case there will be no manager forcing anyone to fix anything.

draw_down 8y ago

This is such a strange reply, talking about whose fault it isn’t. Nobody is asking whose fault it is

zozbot123 8y ago

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.

Asooka 8y ago

But we did get mouse events in the terminal and certainly those didn't exist back in the 70s. Or bracketed paste. It's not hard to imagine that there will be a standard developed (well, 5 standards, then 15 standards and eventually one will remain as the de-facto standard) for keyup events, if there was demand for it.

ori_b 8y ago

> 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. Why would that be? It seems like it would just be a matter of adding another termcap entry for your specific terminal emulator, and hoping other people care enough to start implementing it in theirs. There's already no particularly consistent standard for most terminal events -- just a database of (I think turing-complete) stack VMs that tell programs how to parse whatever they read from the terminal emulator they're running under. Adding another string-named property to this table that describes key-up events would not be overly difficult.

abcdef123xyz123 8y ago
Hi > There's already no particularly consistent standard for most terminal events This is not really true anymore, almost all terminals still in use (and certainly all that are widely used) are VT100 compatible. In fact most are broadly compatible with xterm. So that is pretty much the standard now, and most new features being added to terminals don't take any account of other types of terminal at all. > It seems like it would just be a matter of adding another termcap entry for your specific terminal emulator, and hoping other people care enough to start implementing it in theirs. termcap was superseded by terminfo around the late 80s. A few applications still use it, but most are now terminfo. The termcap database on most systems is now derived from terminfo. terminfo is centrally managed as part of ncurses and stuff doesn't really get added to it just to see. The way it usually works is that one or more terminals add a feature and if it makes sense and is popular, applications will use it, and if applications use it then often it will end up in terminfo entries. Definitely if ncurses uses it, possibly if not (this can be controversial). You are right that there is no real reason a terminal couldn't send an escape sequence for key up, although it would certainly have to be something requested by the application - there are plenty of other escape sequences like that (eg the mouse, focus events). The tty doesn't really come into it, nor does the kernel or drivers, except for its own console terminal, but not many people use that very much. SGR mouse mode is an example of a terminal feature added relatively recently which has been taken up widely.

abcdef123xyz123 8y ago

> So, yes, it's absolutely impossible to get key up events in tty context There is absolutely no reason that many terminal emulators couldn't translate key up events into an escape sequence and forward them on to the application. So long as they receive them somehow themselves (eg an X terminal emulator will be told of them by X). It doesn't need to be out-of-band and it doesn't need to involve the tty driver. The right way to do it is to make them only sent when the application requests them. For example, this is how focus events work. If the application requests them with SM ?1004, \033[I is sent when the window gains focus and \033[O when the window loses it. There are not a lot of applications that use them, but some can (eg vim).