[PATCH] HID: apple: Map Fn+Esc to SysRq
flat view
From: Mikhail Gavrilov <hidden>
Date: 2026-10-27 22:13:14
Also in:
asahi, lkml
Subsystem:
hid core layer, the rest · Maintainers:
Jiri Kosina, Benjamin Tissoires, Linus Torvalds
Apple keyboards have no SysRq/Print Screen key, so nothing on them reports KEY_SYSRQ and the magic SysRq key cannot be used from them without a keymap change. The documented way for keyboards without SysRq is to remap another key to KEY_SYSRQ through the keymap (setkeycodes, EVIOCSKEYCODE, a udev hwdb entry). Compact Apple keyboards have no unused key for that, so the remap gives up a key. The free combinations are in the Fn layer, which the keymap cannot reach: it is indexed by scancode, and Fn does not change the scancode of the key pressed with it. Esc reports usage 0x70029 with and without Fn, so a keymap entry cannot tell Fn+Esc from Esc. hid-apple already implements the Fn layer and uses it to provide PC keys that Apple keyboards lack: Fn+Backspace is Delete, Fn+Enter is Insert, and Fn+arrow keys are Page Up, Page Down, Home and End. Add SysRq to it as Fn+Esc, in the table used by the Magic Keyboard 2021 and 2024 models. No table in hid-apple translates Esc, so today Fn+Esc is just a second Esc key. The new entry has no flags, so like Fn+Enter it is translated only while Fn is held, whether the top row defaults to media keys or to function keys. Fn+Esc then reports KEY_SYSRQ, and the magic SysRq key is Alt + Fn+Esc + command key. Signed-off-by: Mikhail Gavrilov <redacted> --- Tested on the internal keyboard of a MacBook Pro 16" (M1 Max) with the Fedora Asahi Remix 7.1.13 kernel, where hid-apple handles that keyboard with the same magic_keyboard_2021_and_2024_fn_keys table; the table is identical to the one in mainline. In evtest, Esc alone still reports KEY_ESC, and Fn+Esc reports KEY_SYSRQ on press and release, with the Esc scancode 0x70029. Alt + Fn+Esc + H prints the SysRq help to the kernel log. In mainline this table serves the Magic Keyboard 2021 and 2024 models over USB and Bluetooth; that path has not been tested on hardware. Background: this came up on linux-input in 2007 for an Apple USB keyboard. A configurable SysRq keycode was proposed, and the advice was to remap a key of that keyboard to KEY_SYSRQ instead, so that SysRq keeps working with other keyboards [1]; that keyboard had a spare F13. A generic alternative SysRq key was proposed again in 2021 and was not merged; the objection was to adding a new SysRq key regardless of the keyboard [2]. This patch leaves the sysrq code alone and makes the keyboard itself report KEY_SYSRQ, on a Fn combination that has no other function; Apple's list of macOS Fn shortcuts has none with Esc either [3]. The same entry could also go into the other Apple tables for keyboards with a physical Esc, for example older Magic Keyboards and the T2 MacBook Pro models with a dedicated Esc key. I kept this patch to the table I could test. If this is accepted, I will follow up with a line in Documentation/admin-guide/sysrq.rst describing the combination. [1] https://lore.kernel.org/linux-input/d120d5000707160541k64c40d0dgf661226806fd98c8@mail.gmail.com/ (local) [2] https://lore.kernel.org/lkml/YYUxNaDG0DquQvke@kroah.com/T/ (local) [3] https://support.apple.com/en-us/102650 drivers/hid/hid-apple.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 5b32fb8c77f3..b37964451a43 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c@@ -173,6 +173,7 @@ static const struct apple_key_translation magic_keyboard_2015_fn_keys[] = { static const struct apple_key_translation magic_keyboard_2021_and_2024_fn_keys[] = { { KEY_BACKSPACE, KEY_DELETE }, { KEY_ENTER, KEY_INSERT }, + { KEY_ESC, KEY_SYSRQ }, { KEY_F1, KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY }, { KEY_F2, KEY_BRIGHTNESSUP, APPLE_FLAG_FKEY }, { KEY_F3, KEY_SCALE, APPLE_FLAG_FKEY },
--
2.56.0