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?

  • Nothing happens for me when I press Ctrl+Alt+Delete.
    – pfnuesel
    Sep 12, 2017 at 20:02
  • 1
    @pfnuesel That is just an example. The question is general. Pick your own shortcut.
    – luchonacho
    Sep 12, 2017 at 20:04
  • 1
    This seems like more of an IBM PC-history question. Sep 12, 2017 at 20:05
  • Are you talking about X11? Linux console? Sep 13, 2017 at 0:50
  • @MarkPlotnick Well, I tested that on my Linux system. Have not tried it on a windows PC (don't have one at hand).
    – luchonacho
    Sep 13, 2017 at 8:13

2 Answers 2


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


Just like pressing a and then Shift doesn't give you an A, pressing Delete before Alt and Ctrl won't send the right key codes.

The modifier keys need to be pressed before the key that they modify. The modifier keys in this instance are Alt and Ctrl whereas Delete is not a modifier key.

If it was allowed to press a before Shift to get A, the software reading the key presses would not be able to output any character until the next character had been typed.

It's the keyboard hardware that sends different scan codes depending on whether a key was pressed with or without an active modifier.

  • Is there an "official" explanation about this? Do you know what function, script, or code defines this? The answer is intuitive enough, but I would like some sort of confirmation of it.
    – luchonacho
    Sep 13, 2017 at 6:19
  • @luchonacho It's the keyboard hardware that sends different scan codes depending on whether a key was pressed with or without an active modifier.
    – Kusalananda
    Sep 13, 2017 at 6:47
  • Wow, so is this entirely hardware based? There is no software interference? Can this thus not be modified via config/script so that the order is not relevant?
    – luchonacho
    Sep 13, 2017 at 8:14
  • @luchonacho The order of the modifier keys will not be relevant, but the key that they modify must be pressed with the modifier keys already active. This can not be changed in any easy manner, and doing so would probably cause a significant fallout.
    – Kusalananda
    Sep 13, 2017 at 8:16
  • @luchonacho From this point on, the question becomes an academic exercise with on real-world application.
    – Kusalananda
    Sep 13, 2017 at 8:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .