5 ms·

> No, no one can fix this. I don't know about this mythical "one", but I can. I just see no reason to fix it. It is not so hard to make a patch for a /usr/src

by ordu 8y ago

> No, no one can fix this. I don't know about this mythical "one", but I can. I just see no reason to fix it. It is not so hard to make a patch for a /usr/src/linux/drivers/tty/vt.c to make it accept one more esc-seqeuence which would switch terminal into special state, when terminal will send keyup and keydown escape sequences instead of raw-keys for each keypress. A week of tinkering with vt.c and viola, terminal can send keyup and keydown. (Plus maybe one more week to decide how to encode keyups and keydown the best, so ideally terminal would be useable even after wrong esc-sequence sent to it in the wrong time). The right question is: and what? Why might I wish to do this? I might invent some application for this new feature, but I'm pretty sure I couldn't invent something useful what can't be done without keyup event.

derefr 8y ago
That doesn't fix it, on its own. You now also need to make every library and abstraction layer that the packages on your system use be aware of this new feature as well. Can an ncurses program now detect a keyup through this? Can a Docker PTY? Can the JVM? Etc. In most of those cases, because of the historical precedent, these libraries/runtimes don't even have a concept of "keyup" for their TTY-like abstraction, so adding this to them may entail a bit more work than it sounds—especially if, like the JVM, they have a static interface/protocol built in to specify the API of a "TTY-like object", which cannot be changed, since third-parties have compiled code against it and expect that code to remain ABI-compatible with new versions of the runtime.
- cryptonector 8y ago
  Exactly. There's more to it. And yes, it can be done, literally, and I'm sure several participants in this thread could do it. But there's practically no demand, so it won't get done.
- ordu 8y ago
  > You now also need to make every library and abstraction layer that the packages on your system use be aware of this new feature as well. No. You miss the point. I need to do nothing. I have no reason to do anything. Give me a reason and then we can discuss what I need to do. I need a rationale to do something, without rationale my work would be pointless and you might argue indefinitly that anything that I've done already is not enough.
  - derefr 8y ago
    You are the one that said, above, that you could—and I quote—"fix this." "This", in that phrase, stands for the problem in the OP post title—"it being so hard to detect keyup event on Linux." And "on Linux", in the OP post, is a shorthand for "in all the arbitrary applications that exist in the Linux userland, or that one might choose to write in the Linux userland." (You can tell that it has this meaning, because under the more literal meaning of "on Linux"—working within the Linux kernel itself—it is already quite easy to detect keyup events.) Obviously, fixing the entire Linux userland is an unbounded amount of work. That is precisely why the other commenters above are saying that it cannot be done. Not "done" as in "worked upon", but "done" as in "finished."
  - killjoywashere 8y ago
    key-up could give you all sorts of interesting information: you could detect "false zeros" where there are extremely rapid up-down sequences suggestive of motor function disorders in the user (Parkinsonism, etc). You could test the forearm extensors. You could test motor units to exhaustion (hold key until press fails, the "keyup" event). We haven't even gotten to the spinal cord yet, so I'm pretty sure the frontal cortex could be engaged in all sorts of interesting 3rd order ways.
    - ordu 8y ago
      Yes, but why might one want to do it in terminal? You can start Xorg server or Wayland and make it in graphics, where there are no such constraints.

by ordu 8y ago

derefr 8y ago

That doesn't fix it, on its own. You now also need to make every library and abstraction layer that the packages on your system use be aware of this new feature as well. Can an ncurses program now detect a keyup through this? Can a Docker PTY? Can the JVM? Etc. In most of those cases, because of the historical precedent, these libraries/runtimes don't even have a concept of "keyup" for their TTY-like abstraction, so adding this to them may entail a bit more work than it sounds—especially if, like the JVM, they have a static interface/protocol built in to specify the API of a "TTY-like object", which cannot be changed, since third-parties have compiled code against it and expect that code to remain ABI-compatible with new versions of the runtime.

cryptonector 8y ago
Exactly. There's more to it. And yes, it can be done, literally, and I'm sure several participants in this thread could do it. But there's practically no demand, so it won't get done.
ordu 8y ago
> You now also need to make every library and abstraction layer that the packages on your system use be aware of this new feature as well. No. You miss the point. I need to do nothing. I have no reason to do anything. Give me a reason and then we can discuss what I need to do. I need a rationale to do something, without rationale my work would be pointless and you might argue indefinitly that anything that I've done already is not enough.
- derefr 8y ago
  You are the one that said, above, that you could—and I quote—"fix this." "This", in that phrase, stands for the problem in the OP post title—"it being so hard to detect keyup event on Linux." And "on Linux", in the OP post, is a shorthand for "in all the arbitrary applications that exist in the Linux userland, or that one might choose to write in the Linux userland." (You can tell that it has this meaning, because under the more literal meaning of "on Linux"—working within the Linux kernel itself—it is already quite easy to detect keyup events.) Obviously, fixing the entire Linux userland is an unbounded amount of work. That is precisely why the other commenters above are saying that it cannot be done. Not "done" as in "worked upon", but "done" as in "finished."
- killjoywashere 8y ago
  key-up could give you all sorts of interesting information: you could detect "false zeros" where there are extremely rapid up-down sequences suggestive of motor function disorders in the user (Parkinsonism, etc). You could test the forearm extensors. You could test motor units to exhaustion (hold key until press fails, the "keyup" event). We haven't even gotten to the spinal cord yet, so I'm pretty sure the frontal cortex could be engaged in all sorts of interesting 3rd order ways.
  - ordu 8y ago
    Yes, but why might one want to do it in terminal? You can start Xorg server or Wayland and make it in graphics, where there are no such constraints.