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?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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
- Ubuntu 16.04 doesn’t recognize Fn key
- Unable to simulate Ctrl+Shift+Fn+F10 Key press
- Jonathan de Boyne Pollard. “Keyboard mapping”.
console-fb-realizer. nosh toolset manual pages. - Kazutaka Yokota (2008-01-29).
atkbd. FreeBSD manual pages. kbdmap. §5. FreeBSD manual pages.
Method 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.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0