Difference between revisions of "Map scancodes to keycodes"

From ArchWiki
Jump to: navigation, search
m (Internationalization)
m (Bot: Removing from Category:General (English))
Line 1: Line 1:
{{i18n|Map scancodes to keycodes}}
{{i18n|Map scancodes to keycodes}}
[[Category:General (English)]]
[[Category:Input devices (English)]]
[[Category:Input devices (English)]]
[[Category:Other desktop user's resources (English)]]
[[Category:Other desktop user's resources (English)]]

Revision as of 01:37, 10 June 2011

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Tango-document-new.pngThis article is a stub.Tango-document-new.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Map scancodes to keycodes#)

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.

There are three ways of mapping scancodes to keycodes:

  • Using udev
  • Using HAL
  • Using the kernel tool 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 (as does HAL, but it is now deprecated). 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.

Using udev

First, you need to create a keymap file that udev will recognise. Some examples can be found in /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

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

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

$ /lib/udev/findkeyboards

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+="keymap $name /path/to/keymap"

If you place the keymap file in /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:

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

Using HAL

See HAL Keymap Quirks.

Using the kernel tool setkeycodes

See the detailed article: setkeycodes.