3

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?

luchonacho
  • 823

2 Answers2

7

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

JdeBP
  • 68,745
2

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.

Kusalananda
  • 333,661
  • 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 '17 at 06: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 '17 at 06: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 '17 at 08: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 '17 at 08:16
  • @luchonacho From this point on, the question becomes an academic exercise with on real-world application. – Kusalananda Sep 13 '17 at 08:26
  • See other answer, which has an opposite opinion. – luchonacho Sep 13 '17 at 10:15
  • @luchonacho Not opposite. How do you mean? It's more detailed, yes, but still, the scan codes still has to be sent in the correct order by the hardware. – Kusalananda Sep 13 '17 at 10:19
  • Mmm, let me digest all this and see if I can understand this better. – luchonacho Sep 13 '17 at 10:23