[Ubuntu Wiki] Update of "Hotkeys/Troubleshooting" by pitti

[Ubuntu Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The "Hotkeys/Troubleshooting" page has been changed by pitti:
http://wiki.ubuntu.com/Hotkeys/Troubleshooting?action=diff&rev1=40&rev2=41

Comment:
update for evtest, as udev's keymap tool went away in 13.10

     * in some cases the keybindings may be wrong, perhaps due to a legacy (i.e., pre-evdev) keymap.   You can check your keymap using `gconf-editor` and looking under `/apps/gnome_settings_daemon/keybindings`.  Bindings without sensible key names are probably bugs.
     * for audio volume control hotkeys, gnome-sound-properties may be misconfigured. You can either examine with gconf-editor '/desktop/gnome/sound' or do 'gconftool --recursive-list /desktop/gnome/sound' to get the current settings; the particular configuration items are 'default_mixer_tracks' and 'default_mixer_device'.
    a. if there are too many keypress events then you need to determine where they are being duplicated.
-  1. if the key code is wrong, or there is no keypress event, or the key only works once and then the desktop gets "stuck", exercise the "Fixing broken keys" section in /usr/share/doc/udev/README.keymap.txt (Ubuntu 9.10 and later).
+  1. if the key code is wrong, or there is no keypress event, or the key only works once and then the desktop gets "stuck", install the "evtest" package, run `sudo evtest`, select your keyboard device, press the broken keys, and note down their scan code (MSC_SCAN), current keycode (KEY_*), and intended meaning.
-   a. If that was successful, file a bug against udev ("ubuntu-bug udev") and attach your newly created keymap and rule.
+   a. If that was successful, file a bug against udev ("ubuntu-bug udev") and add the scan code → meaning map.
-   a. If udev's keymap tool shows a correct key symbol, look up the symbolic name in /usr/include/linux/input.h.  If it is mapped to a code over 255 (over 0x0ff), then it is outside X's range see [[https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/313514|bug 313514]].  In this case, if it is important to have the key mapped, the key should be remapped to an appropriate value < 256.
+   a. If evtest shows a correct key symbol, look up the symbolic name in /usr/include/linux/input.h.  If it is mapped to a code over 255 (over 0x0ff), then it is outside X's range see [[https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/313514|bug 313514]].  In this case, if it is important to have the key mapped, the key should be remapped to an appropriate value < 256.
   1. If the events are reported by more than one input device then report a kernel bug (Ubuntu `linux` package) because it should only send the event on one device.
   1. if not found with `keymap`, use `acpi_listen` to determine whether the key is coming through as an ACPI event instead of a keypress
    a. if there is an ACPI event but no keypress, this is a bug in the kernel (ubuntu-bug linux) for not translating the ACPI event to an input event.