Why is the order in which shortcuts keys are executed important

keyboard shortcuts

Press Ctrl and hold it. Then, press Alt and hold it. Finally, press Delete. If you have a Ubuntu system (maybe any debian-based system), it is very likely that your session will be locked, as you have executed the Ctrl+Alt+Delete shortcut.

Now, press Delete and hold it. Then press Ctrl and hold it. Then, press Alt. The lock session shortcut is not going to be triggered.

Why is this the case? Where is this setting hard-coded?

My guess: I get the impression that shortcuts work by virtually "extending the keyboard keys". Thus, selecting Ctrl or Alt open a "new keyboard", of which you selected the key Delete. That is however not the same when you select Delete first, which belongs to the physical keyboard and not to this virtual, extended keyboard. Is this the case?

Best Answer

Because non-modifier actions are enacted on the key down event.

This is actually almost nothing to do with keyboard hardware. Both USB and PS/2 keyboards operate the same in this respect. There is nothing in the hardware that makes so-called "modifier keys" special. Any key, with one exception, can be a modifier key or not.

What determines what is a modifier key is the keyboard map employed in software in an operating system. The hardware just sends what are in effect (glossing over the details of the USB HID input report protocol actually being a bitmap of currently pressed keys that is partly encoded into an inside-out form to keep it short) key down and key up events.

In a FreeBSD keyboard map, for example, one finds lines such as this:

#                                                         alt
# scan                       cntrl          alt    alt   cntrl lock
# code  base   shift  cntrl  shift  alt    shift  cntrl  shift state
# ------------------------------------------------------------------
…
029   lctrl  lctrl  lctrl  lctrl  lctrl  lctrl  lctrl  lctrl   O
…
042   lshift lshift lshift lshift lshift lshift lshift lshift  O
…
054   rshift rshift rshift rshift rshift rshift rshift rshift  O
…
056   lalt   lalt   lalt   lalt   lalt   lalt   lalt   lalt    O
…
083   del    '.'    '.'    '.'    '.'    '.'    boot   boot    N
…

029, 042, 054, and 056 are the keyboard codes (normalized into a common system from the USB HID usage numbers and the PS/2 scancode numbers) but it is the lctrl, lshift, rshift, and lalt actions in the map that define these keys to be modifier keys. Define them with different actions and move these actions elsewhere, as indeed several out-of-the-box FreeBSD maps do, and entirely different keys are modifiers.

(The exception to the rule is the Fn key, which is the one modifier that is implemented in hardware. It is implemented entirely in hardware and not seen by software at all. It does not even generate any events over the wire. There's actually another hardware modifier, too. It isn't a key. It's the state of the NumLock LED.)

The action, when it is a modifier action such as this, changes the current modifier state, which (simply put) is a set of flags recorded in the operating system that record what modifiers are currently "on". As you can see from the column headings in the keyboard map, the current modifier state — in terms of "on" flags for "shift", "altgr", "control" and "alt" states — influences what action further keypresses map to.

On the line for key code 083, which is the one engraved . del on the numeric keypad, you can see that only if the current modifier state is at least "alt cntrl" will the mapped action be boot.

Keyboard drivers enact modifier actions upon receiving key press or key release events. Other actions, however, only take effect upon key press or autorepeat events. This is the case for the boot action, for example. Only if a key press or autorepeat event for key 083 occurs and the current modifier state is already "alt cntrl"/"alt cntrl shift", does the boot action happen.

It should be obvious from this that in order to get the operating system's current modifier state into that state in the first place, the lalt and lctrl/rctrl actions must have already happened, by first pressing the keys that happen to be mapped to them. (FreeBSD's system also allows for modifier locks in addition to the usual system of modifier shifts, although only two keyboard maps out-of-the-box make any use of them at all. The ISO keyboard standard also allows for modifier latches, but FreeBSD does not provide this mechanism.)

FreeBSD is, as I said, an example here. But most operating systems with PS/2 or USB HID devices, from MS/PC-DOS (where the current modifier state is a well-known byte in memory) to Windows NT (where keyboard maps are kernel-mode DLLs containing code and data), work in roughly this way.

Further reading

Related Question