then check xev again. if you combine this with the acpi_osi="!Windows 2012" boot option, you may get weird results in xev, so try not using it. If this did fix things, make sure to make the module load at boot with methods described [[Kernel Modules|here]]

then check xev again. if you combine this with the acpi_osi="!Windows 2012" boot option, you may get weird results in xev, so try not using it. If this did fix things, make sure to make the module load at boot with methods described [[Kernel Modules|here]]

+

+

== See also ==

+

+

* [http://keytouch.sourceforge.net/howto_keyboard/node4.html How to retrieve scancodes] by Marvin Raaijmakers

Prerequisite for modifying the key mapping is knowing how the keys are identified on the system. There are multiple levels:

A scancode is the lowest identification number for a key, it is the value that a keyboard sends to a computer.

A keycode is the second level of identification for a key, a keycode corresponds to a function.

A keysym is the third level of identification for a key, it corresponds to a symbol. It may depend on whether the Shift key or another modifier key was also pressed.

Scancodes are mapped to keycodes, which are then mapped to keysyms depending on used keyboard layout. Most of your keys should already have a keycode, or at least a scancode. Keys without a scancode are not recognized by the kernel.

Identifying key codes

Scancodes

Using showkey

The universal way to get a scancode is to use the showkey utility. showkey waits for a key to be pressed and if none is during 10 seconds it quits, which is the only way to exit the program. To execute showkey you need to be in a virtual console, not in a graphical environment. Run the following command

# showkey --scancodes

and try to push keyboard keys, you should see scancodes being printed to the output.

Using dmesg

Note: This method does not provide scancodes for all keys, it only identifies the unknown keys.

You can get the scancode of a key by pressing the desired key and looking the output of dmesg command. For example, if you get:

Unknown key pressed (translated set 2, code 0xa0 on isa0060/serio0

then the scancode you need is 0xa0.

Keycodes

Warning: Note that the keycodes are different for Linux console and Xorg. Use the appropriate tool to determine the desired value.

In console

The keycodes for virtual console are reported by the showkey utility. showkey waits for a key to be pressed and if none is during 10 seconds it quits, which is the only way to exit the program. To execute showkey you need to be in a virtual console, not in a graphical environment. Run the following command

# showkey --keycodes

and try to push keyboard keys, you should see keycodes being printed to the output.

In Xorg

The keycodes used by Xorg are reported by a utility called xev, which is provided by the xorg-xev package. Of course to execute xev, you need to be in a graphical environment, not in the console.

With the following command you can start xev and show only the relevant parts:

In the example the keys a, r, c, h and two other multimedia keys were pressed. The former four keys with keycodes38, 27, 54 and 43 are properly mapped, while the multimedia keys with keycodes153 and 144 are not. The NoSymbol indicates that no keysyms are assigned to those keys.

If you press a key and nothing appears in the terminal, it means that either the key does not have a scancode, or the scancode is not mapped to a keycode.

2.6 kernels

Note: In 2.6 kernels raw mode, or scancode mode, is not very raw at all. Scan codes are first translated to key codes, and when scancodes are desired the key codes are translated back...there is no guarantee at all that the final result corresponds to what the keyboard hardware did send. To change behavior back to the old raw mode, add the parameter atkbd.softraw=0 to your kernel while booting. This can be removed for later boots when the old raw functionality is not required.

This is relevant if the keymaps obtained from showkey and the ones set by setkeycodes differ from the ones obtained by xev in X. Keep this in mind when translating the keymaps into keysyms using xmodmap (See Extra Keyboard Keys in Xorg).

Asus N56VJ (or possibly others)

if most of your special keys don't work, try loading the asus-nb-wmi kernel module with

# modprobe asus-nb-wmi

then check xev again. if you combine this with the acpi_osi="!Windows 2012" boot option, you may get weird results in xev, so try not using it. If this did fix things, make sure to make the module load at boot with methods described here