Remapping SysRq in Linux

Question

The designers of my new keyboard decided that for some f:in reason the PrintScreen key must sit between AltGr and RCtrl.

So now I have this problem: I like having the magic SysRq key available because it has been useful every now and then. But now I have, for example, AltGr+k mapped to downarrow and a moment ago when I wanted to use this downarrow combination, I accidentally pressed AltGr+PrintScreen+k and all programs were killed. This is extremely annoying.

Is there any way to remap sysrq somewhere else? Like AltGr+delete or something.

Answer 1

I just ran into this problem on my new laptop. My solution was to patch drivers/tty/sysrq.c in the kernel to add

#undef KEY_SYSRQ
#define KEY_SYSRQ KEY_VOLUMEDOWN

right after all the #includes. If volume-down is not an appropriate key for you, you can find other keycodes in include/uapi/linux/input-event-codes.h.

I don't see any way to do this remapping without modifying the kernel. If that's not an option, one can at least use /proc/sys/kernel/sysrq as described in the kernel's sysrq documentation to disable the more dangerous requests:

echo 0x1A >/proc/sys/kernel/sysrq

This only enables control of logging levels, process dumps and sync. Most of the other categories will probably interrupt your work after an accidential trigger.

Answer 2

Remapping via scancode-keycode-remapping (kernel side)

Via udev:

Another way could be remapping scancodes to keycodes. /lib/udev/hwdb.d/60-keyboard.hwdb gives on my system a good introduction about what to do (it is verbosely documented), alternatively: You can read for example here, and so I created a file 94-gpd-micropc-keyboard.hwdb for my computer which contains

[...]
evdev:atkbd:dmi:bvn*:bvr*:bd*:br*:efr*:svnGPD:pnMicroPC:*
  KEYBOARD_KEY_36=sysrq  # Right Shift -> SysRq
[...]

(see full file for more more general documentation in the comments)

and afterwards I run udevadm --debug hwdb --update and then udevadm trigger /dev/input/<my-input-device> to load it without reboot.

Now the right shift is the SysRq key and it works as SysRq, without doing anything to the kernel's code.

Note:

• With the evdev:*-line it can be fine-tuned to which keyboards the settings should be applied.

Directly without udev, via setkeycodes:

There is also an option without involving udev, via setkeycodes, and what you need you can infer from showkey -s. (Only on the Linux text console, not in X Server and probably not in wayland.)

Note:

• this applies to all AT/ PS/2-connected keyboards,
• this seems to ignore USB-connected keyboards.

---

To un-map your original SysRq key, the same should work to map the SysRq key to something else. Since I don't have a physical SysRq key I cannot test and query it's scancode via showkey (setkeycodes-method) or evtest (udev-method).

---

I actually would like to have SysRq only be registered when a modifier key is pressed, e.g. <Ctrl>+<Right Shift>, so that "normal" right shift still stays as such. Any idea if that can be achieved without changing the keyboard controller's firmware?

Answer 3

The answer depends on whether you are running X (a current generation gui desktop) or not. You didn't specify.

Running X:

There are several ways to handle this.

The most precise/limited way is to use xmodmap. I haven't used it, so I'm not familiar with the details. It will remap keys with specific key codes to specific key symbols.

If you have trouble sorting things out, run xev. When you press any key combination (or do other X things), xev will tell you what the system saw which will give you the values you need for xmodmap.

Once you get the command to work, you can run it from your ~/.login script so it's there when you start an interactive shell. Or, you can add it as a bash script into your desktop environment's autostart system.

If you want to do more, you may want to check out AutoKey which is a desktop automation tool. Among other things, you can define a macro which will be triggered by a simple or compound keypress which can do anything from just emitting another keypress to running a complex macro coded in Python which can do almost anything you can think of - if you know enough Python.

I use it every day and love it.

For simpler things along the same lines, check out xdotool. It can also do a few things which AutoKey currently can't do - like emit mouse events.

Not running X (server installation, etc.):

This is a lot harder to find information on because it's a much less common case.

I've never tried it, but I did find some information on it here yesterday answering another question.