Why does PAUSE key have a long make code and no break code?

Question

On IBM keyboards, scan code sets 1 and 2 have a long make code and lack a break code for the Pause/Break key. Moreover, when Ctrl is pressed, the make code is different, although break code still doesn't exist.*

In scan code set 3 there does appear the break code, but this set isn't used much.

What was the reason for Pause/Break to be treated so specially to not even have a break code?

---

_{^*See detailed tables in e.g. this spec for EM83053DH keyboard encoder. I've checked experimentally that description for Pause/Break is correct at least with set 2 active.}

Answer 1

In scancode set 2, the "break" scancodes consist of the "make" scancodes prefixed by F0. This is consistent across nearly all the keys. Some keys include a modifier prefix in the Ex range as well, and this is repeated in the "break" sequence. Additionally some keys behave as if two keys are pressed at once, and thus include multiple F0 codes to ensure that both virtual keys are seen as released by the host PC.

The "make" scancode for the Pause/Break key, however, is E1 14 77 E1 F0 14 F0 77. Examining this closely, this is actually a combined "make" then "break" sequence for a composite scancode: E1 14 77, then E1 F0 14 F0 77. So when you press that key, it is seen as pressed only momentarily by the host PC, even if you hold it down.

Yes, this is a hopeless mess. I think it resulted from the gradual evolution of the PC keyboard through its early history. The USB-HID scancode set is completely different, this obviously being seen as an opportunity to discard the cruft.

Answer 2

A minor (and late) addition to Chromatix otherwise complete answer:

Pause as well as Break are intended to work as 'interrupt' keys. This implies a few differences from any other key:

• Any press is supposed to be reported (*1) right away
• Any press should be responded to (*2) as soon as possible
• They should not be repeated under any circumstances.

Reporting of a key can happen, depending on keyboard driver strategy on key press or key release, sending both at once will make sure it gets reported no matter what strategy is used.

Responding can happen, depending on driver/OS/User strategy on key press or key release, sending both at once will make sure it gets handled ASAP no matter what strategy is used.

Eventually even more important, by sending the release right after press, no typematic (key repeating) functionality gets a chance to multiply its 'interrupt message' if a user presses either key for a prolonged time. Just imagine how a program, using Pause to stop and restart scrolling, would start to act...

Bottom line: This is all about 'hacking' the keyboard driver strategy from 'below'

---

*1 - To User/OS level, i.e. past any driver

*2 - By User/OS level, i.e. past any driver

Answer 3

As Chromatix wrote, the code indicates: press E1 14, press 77, release E1 14, release 77. So which keys are these?

77 is NumLock. E1 14 is unused.

But E0 14 is right Ctrl, and 14 is left Ctrl. This E0 pattern is also followed for all the other keys that have two copies.

So we can infer that the Pause key simulates pressing Ctrl+NumLock, probably because that combination was recognized by the PC BIOS when this key was introduced. But not right or left Ctrl, possibly to avoid messing things up if the user was already holding down the Ctrl key, or to allow sufficiently advanced operating systems to distinguish this from actual Ctrl+NumLock.

Why is there no break code? Probably because it's not clear what it would mean to hold down a fake key combination like this. What should happen if you are holding down Pause and then you press NumLock? Releasing NumLock should release Pause but act as if Ctrl is still held down? Should all your other keypresses be interpreted as if you are holding Ctrl?