Ctrl-c then nothing else causes repeated ctrl-c to be sent.

[payonel]

yes, this is one of the disadvantages to ocvm and the fact that it runs in pty. In a real master tty (generally available on tty0 through tty12) I can get true RAW kb codes, which include key_up. On pty, and terminal emulators in general (e.g. within an X environment), I do not and cannot get RAW kb codes, but only MEDIUMRAW, which DO NOT include nice things such as KEY_UP, nor modifier key_down codes (such as CONTROL). Instead, I have mapped all the possible combinations of modifiers with keys and created a massive mapping. Then I reverse lookup what key and modifier was likely pressed. There are overlaps making it impossible to distinguish some combinations. Thus I also have to preserve/cache the state of modifiers, and I have to wait for a new key_down event and update the state of the modifiers. If the modifiers change state then I can send a key_up

Thus, if you press ^c, openos sees

1. key_down CONTROL
2. key_down c

And I cannot see the (real) key up. Later, if you press (e.g.) just "c" without CONTROL, ocvm can reverse lookup that code and update the modifier state of CONTROL, and openos sees:

1. key_up CONTROL
2. key_down c

But in the interim, openos' "soft interrupt" handler sees that the user has not released CONTROL+C

Note that due to overlap in the "Reverse Lookup" mapping of codes to keys, there are some combos that LOOK INDISTINGUISHABLE from just plain "escape", which ocvm uses to abort the vm. For example, CONTROL+ALT+C looks like escape...unfortunately. I could later decide that CONTROL+ALT+C is decoded, instead of ESCAPE, and either not have a vm abort key or have something else as the abort key. During development I needed to abort the vm A LOT and escape was a reasonable test key at that time.

[payonel]

@AmandaCameron had a great idea (given in irc) to use a timeout, expecting key-repeat. If no repeat occurs ocvm could assume the key_up

[payonel]

closed with 4667b5f32fefc37ad51eac5a9e5574f3e7714fd8