Difference between revisions of "Map scancodes to keycodes"

From ArchWiki
Jump to: navigation, search
m (Using udev: Out-of-date since systemd 206)
(update)
Line 1: Line 1:
 
[[Category:Keyboards]]
 
[[Category:Keyboards]]
{{stub}}
+
[[Wikipedia:Scancode|Scancodes]] are the lowest identification numbers for a key, it is the value that a keyboard sends to a computer. ''Scancodes'' are mapped to ''keycodes'', which are then mapped to ''keysyms'' depending on used keyboard layout. Mapping ''scancodes'' to ''keycodes'' is universal and not specific to Linux console or Xorg, which means that changes to this mapping will be effective in both.
scancodes are the lowest identification numbers for a key, they are from the kernel and are not used by applications that's why we have to map them to keycodes which correspond to functions.
+
  
 
''See [[Extra Keyboard Keys]] for more information.''
 
''See [[Extra Keyboard Keys]] for more information.''
  
There are three ways of mapping scancodes to keycodes:
+
There are two ways of mapping ''scancodes'' to ''keycodes'':
*Using [[udev]]
+
* Using [[udev]]
*Using the kernel tool {{ic|setkeycodes}}
+
* Using ''setkeycodes''
  
The preferred one is to use udev because it uses hardware information (which is a quite reliable source) to choose the keyboard model in a database. It means that if your keyboard model as been defined in the database, your keys are recognized "out of the box" and can be seen by Xorg. That's why by expanding the database you are helping the linux community and maybe someday we won't have to care about scancodes.
+
The preferred method is to use ''udev'' because it uses hardware information (which is a quite reliable source) to choose the keyboard model in a database. It means that if your keyboard model has been found in the database, your keys are recognized ''out of the box''.
  
 
== Using udev ==
 
== Using udev ==
 +
 
{{Out of date|Since systemd 206, the tools described here have been replaced by hwdb and the "keyboard" udev builtin}}
 
{{Out of date|Since systemd 206, the tools described here have been replaced by hwdb and the "keyboard" udev builtin}}
 +
 
First, you need to create a keymap file that udev will recognise. Some examples can be found in {{ic|/usr/lib/udev/keymaps/}}, and you should use one of these if it works for your keyboard model. Otherwise, you need to create one yourself. The format of each line in a keymap is '<scancode> <keycode>'. You can work out <scancode> (looks like 0xXX) using:
 
First, you need to create a keymap file that udev will recognise. Some examples can be found in {{ic|/usr/lib/udev/keymaps/}}, and you should use one of these if it works for your keyboard model. Otherwise, you need to create one yourself. The format of each line in a keymap is '<scancode> <keycode>'. You can work out <scancode> (looks like 0xXX) using:
 +
 
  # /usr/lib/udev/keymap -i input/eventX
 
  # /usr/lib/udev/keymap -i input/eventX
 +
 
and pressing the relevant keys. Replace input/eventX with your keyboard device, which can most of the times be found by running:
 
and pressing the relevant keys. Replace input/eventX with your keyboard device, which can most of the times be found by running:
 +
 
  $ /usr/lib/udev/findkeyboards
 
  $ /usr/lib/udev/findkeyboards
If it is not correct, you have to try with other eventX devices.  
+
 
The choices for <keycode> are listed as KEY_<KEYCODE> in {{ic|/usr/include/linux/input.h}}, but you need to change these to lower case and remove the KEY_ prefix (for example, KEY_PROG3 corresponds to prog3). A sorted list is available [http://hal.freedesktop.org/quirk/quirk-keymap-list.txt here].
+
If it is not correct, you have to try with other eventX devices. The choices for <keycode> are listed as KEY_<KEYCODE> in {{ic|/usr/include/linux/input.h}}, but you need to change these to lower case and remove the KEY_ prefix (for example, KEY_PROG3 corresponds to prog3). A sorted list is available [http://hal.freedesktop.org/quirk/quirk-keymap-list.txt here].
  
 
Once you have a keymap, you need to tell udev to use it. This can be done with a [[Udev#About udev rules|udev rule]]. Here is a simple example:
 
Once you have a keymap, you need to tell udev to use it. This can be done with a [[Udev#About udev rules|udev rule]]. Here is a simple example:
 +
 
  SUBSYSTEM=="input", ATTRS{name}=="AT Translated Set 2 keyboard", RUN+="/usr/lib/udev/keymap input/$name /path/to/keymap"
 
  SUBSYSTEM=="input", ATTRS{name}=="AT Translated Set 2 keyboard", RUN+="/usr/lib/udev/keymap input/$name /path/to/keymap"
 +
 
If you place the keymap file in {{ic|/usr/lib/udev/keymaps/}}, you can omit the full path. Now the keymap will be active the next time you restart. You can run the following command to activate it immediately:
 
If you place the keymap file in {{ic|/usr/lib/udev/keymaps/}}, you can omit the full path. Now the keymap will be active the next time you restart. You can run the following command to activate it immediately:
 +
 
  # /usr/lib/udev/keymap input/eventX /path/to/keymap
 
  # /usr/lib/udev/keymap input/eventX /path/to/keymap
  
 
For more information about keymaps and how to send them upstream, see {{ic|/usr/share/doc/systemd/README.keymap.txt}}.
 
For more information about keymaps and how to send them upstream, see {{ic|/usr/share/doc/systemd/README.keymap.txt}}.
  
== Using the kernel tool <code>setkeycodes</code> ==
+
== Using setkeycodes ==
 +
 
 
''See the detailed article: [[setkeycodes]].''
 
''See the detailed article: [[setkeycodes]].''

Revision as of 13:13, 11 September 2013

Scancodes are the lowest identification numbers for a key, it is the value that a keyboard sends to a computer. Scancodes are mapped to keycodes, which are then mapped to keysyms depending on used keyboard layout. Mapping scancodes to keycodes is universal and not specific to Linux console or Xorg, which means that changes to this mapping will be effective in both.

See Extra Keyboard Keys for more information.

There are two ways of mapping scancodes to keycodes:

  • Using udev
  • Using setkeycodes

The preferred method is to use udev because it uses hardware information (which is a quite reliable source) to choose the keyboard model in a database. It means that if your keyboard model has been found in the database, your keys are recognized out of the box.

Using udev

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Since systemd 206, the tools described here have been replaced by hwdb and the "keyboard" udev builtin (Discuss in Talk:Map scancodes to keycodes#)

First, you need to create a keymap file that udev will recognise. Some examples can be found in /usr/lib/udev/keymaps/, and you should use one of these if it works for your keyboard model. Otherwise, you need to create one yourself. The format of each line in a keymap is '<scancode> <keycode>'. You can work out <scancode> (looks like 0xXX) using:

# /usr/lib/udev/keymap -i input/eventX

and pressing the relevant keys. Replace input/eventX with your keyboard device, which can most of the times be found by running:

$ /usr/lib/udev/findkeyboards

If it is not correct, you have to try with other eventX devices. The choices for <keycode> are listed as KEY_<KEYCODE> in /usr/include/linux/input.h, but you need to change these to lower case and remove the KEY_ prefix (for example, KEY_PROG3 corresponds to prog3). A sorted list is available here.

Once you have a keymap, you need to tell udev to use it. This can be done with a udev rule. Here is a simple example:

SUBSYSTEM=="input", ATTRS{name}=="AT Translated Set 2 keyboard", RUN+="/usr/lib/udev/keymap input/$name /path/to/keymap"

If you place the keymap file in /usr/lib/udev/keymaps/, you can omit the full path. Now the keymap will be active the next time you restart. You can run the following command to activate it immediately:

# /usr/lib/udev/keymap input/eventX /path/to/keymap

For more information about keymaps and how to send them upstream, see /usr/share/doc/systemd/README.keymap.txt.

Using setkeycodes

See the detailed article: setkeycodes.