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.

3 Answers 3


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

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.

  • I have seen that in include/uapi/linux/input-event-codes.h there is #define KEY_SYSRQ 99, and in usr/include/linux/input-event-codes.h there is #define KEY_SYSRQ 99. Maybe that's a cleaner way to redifine it by redifining it there? Oct 28, 2022 at 12:25
  • @GolarRamblar I don't think that's a good idea. To the kernel, SYSRQ is the name of that key, much like F12 or A. That header is also used in user space, you can find it in /usr/include/linux as well. I just want to change which key triggers the sysrq action and not mess up the input system. The proper solution would of course be to make the sysrq trigger configurable via boot parameter and/or some /proc file. For a hack like this. you usually want to make the smallest possible change.
    – wrtlprnft
    Nov 1, 2022 at 7:32
  • Thanks for the explanation, @wrtlprnft. -- What are the problems with remapping it by modifying the scancodes-keycodes-mapping after bootup within the kernel? For me, this at least makes a new key behaving as SysRq. I cannot test if that makes the old one not behaving anymore as SysRq, because I don't have that key physically. Nov 2, 2022 at 11:13
  • @GolarRamblar Woudn't that completely remap the target key? i. e. if I remapped the volume-down key of my keyboard to SYSRQ and mapped the printscreen key to something useless like F13, wouldn't both keys stop working for their normal purpose? Of course, I could then tell KDE to reduce the volume on SYSRQ, but if I then plug in an external keyboard, that would also have the same strange mapping. Also note that patching and compiling Linux seems to be far easier (to me) than messing with udev.
    – wrtlprnft
    Nov 2, 2022 at 19:00
  • Yes, @wrtlprnft, that completely remaps the key. But you can also swap key assignments this way (given you do it one-shot, not sequentially, at least with setkeycodes you have to do all remappings where you have a chain of moving keys arounf within one command). The udev method works per device: You can specify which device(s) to apply the rules to, so you can limit it to the internal keyboard. And the setkeycodes method somehow does not work for USB keyboards. Nov 4, 2022 at 12:17

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

  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.


  • 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.)


  • 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?


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.

  • 6
    Actually I already remapped the key but it seems the kernel captures the sysrq combinations before X sees them or something.
    – nonpop
    Feb 17, 2015 at 9:04
  • Upon rereading your question, I see that I missed that you had already done that.
    – Joe
    Sep 1, 2015 at 7:28

You must log in to answer this question.

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