Troubleshooting

Differences between revisions 28 and 29
Revision 28 as of 2009-04-22 17:36:11
Size: 7874
Editor: c-24-21-50-133
Comment:
Revision 29 as of 2009-04-22 17:38:49
Size: 7874
Editor: c-24-21-50-133
Comment:
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
 1. if `gnome-settings-daemon` or `gnome-power-manager` is running, stop it first with `killall gnome-settings-daemon gnome-power-manager`; these daemons grab some X events exclusively and prevent them from being seen with `xev'.  1. if `gnome-settings-daemon` or `gnome-power-manager` is running, stop it first with `killall gnome-settings-daemon gnome-power-manager`; these daemons grab some X events exclusively and prevent them from being seen with `xev`.

This page details the process of debugging the behavior of hotkeys/media keys in Ubuntu. See Hotkeys/Architecture for an overview of the architecture used for handling hotkey events.

Involved Components

ACPI events cross a lot of different layers, and determining the component that is handling them can take quite a bit of digging. Below is a non-comprehensive list of components which have been known to handle hotkey events:

Packages involved in acting on hotkey events:

  • gnome-power-manager - handles brightness and power hotkeys. Displays a popup 'OCD' display
  • gnome-settings-daemon (handles visual feedback of volume changes, display toggling)
  • gnome-control-center (gnome-sound-properties, gnome-keybinding-properties)
  • pm-utils
  • acpi-support
  • gdm

Packages involved in propagating hotkey events to where they belong:

  • hotkey-setup
  • xserver-xorg-input-evdev
  • linux kernel
  • hal
  • hal-info (model specific keycode to key symbol mapping)
  • xkeyboard-config

Note that the 'acpi' source package is *not* involved in any of this, although many acpi/hotkey issues get (incorrectly) filed against it. 'acpi' is just a command line tool for listing info about acpi devices.

Step-by-step Troubleshooting

  1. if gnome-settings-daemon or gnome-power-manager is running, stop it first with killall gnome-settings-daemon gnome-power-manager; these daemons grab some X events exclusively and prevent them from being seen with xev.

  2. run xev to test whether a keypress event is seen:

    xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'
  3. if there's a keypress event:
    1. if the keycode is right, it's a desktop issue; see the list of packages that act on hotkey events for further diagnosis (gnome-settings-daemon, gnome-power-manager, ...)

      • 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'.
    2. if the keycode itself is wrong, this is a bug in xkeyboard-config.

    3. if there are too many keypress events then you need to determine where they are being duplicated.
  4. if there's no keypress event, it's an issue with lower-level systems; switch to the console to troubleshoot further.
  5. enumerate the available input devices as seen by hal:

    hal-find-by-capability --capability input | xargs -n1 lshal -u
  6. look at the names of the input devices (info.product) and look for likely names and names that can be ruled out

  7. attach to the devices one by one using sudo input-events <devnum> (in the input-utils package), using the number returned by lshal as part of input.device, and press the hotkey to see if an event is generated

  8. if the event is found with input-events with a proper symbolic key name:

    1. if lshal shows input.keys for the device (in info.capabilities) and input.x11_driver is set to evdev but X doesn't see it, this normally indicates that the keycode is outside the range permitted by X input; either it will need to be handled by hal or remapped to a lower keycode by hal-info, so file a bug against hal. To verify this, 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 bug 313514. In this case, if it is important to have the key mapped, the key should be mapped to an appropriate value <256.

    2. if lshal does *not* show both input.keys and input.x11_driver="evdev", this is a bug in hal or in some desktop component that should be listening for that event via hal

    3. check /var/log/Xorg.0.log to see if there are any messages relating to the input device in question

  9. if the event is found with input-events, but has an unknown symbolic key name:

    1. note down the "code" and "value" numbers of that key, together with its intended functionality (e. g. "brightness down")
    2. file a bug against hal-info with the mapping figured out above, and the output of lshal |grep system.hardware.

  10. 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.

  11. if not found with input-events, use acpi_listen to determine whether the key is coming through as an ACPI event instead of a keypress

  12. if there is an ACPI event but no keypress, this is a bug in the kernel (Ubuntu linux package) for not translating the ACPI event to an input event

  13. if there is neither an ACPI event nor an input event, this is probably also a kernel bug, though probably harder to diagnose (WMI, perhaps?)

Useful Information to Collect in Reports

  • hal-find-by-capability --capability input | xargs -n1 lshal -u > lshal.log

  • lshal |grep system.hardware

  • dmesg > dmesg.log

  • sudo lsinput > lsinput.log

  • xkbcomp -xkb :0 - > xkbcomp.txt

  • setxkbmap -print > xkbmap.txt

Troubleshooting Tricks and Tips

  • Testing: Before making changes, make a list of all your keys and hit each of them in turn, and record how they work. Repeat this after every change, so you'll know if a change fixed one thing but broke something else.
  • Run gnome-power-manager in verbose mode (gnome-power-manager --no-daemon --verbose) to get detailed debug info

  • In some cases, hotkeys are communicated correctly to X but applications are listening for them as dbus events generated by hal. Use lshal -m to monitor which hotkey events are being produced by hal.

  • Experiment with the scripts in /etc/acpi/. These come into play only for *some* hardware and are being phased out, so may not be relevant for your case.
  • To test sleep modes directly, echo S3 > /proc/acpi/sleep

  • Switch to a virtual terminal and back (e.g. ctrl+alt+F1 ; ctrl+alt+f7) and see if that resets things
  • Switch to the Guest Account and see if the issue can be reproduced.
  • Boot a LiveCD and try reproducing it there. If you can't, it suggests either a modification to your system or a software update not present on the LiveCD.
  • Create a test user account, log out of all sessions and into that one. If you can't reproduce the issue there, then suspect some stored gconf or other settings in your dot files. (This is less likely if you've recently done a fresh install, vs. upgraded from past versions of Ubuntu.)
  • If the key used to work properly at one time, and you've narrowed the problem to a specific component, then try testing different past versions of that package to try to bracket where the regression first started. This can help narrow down what patch might have caused the problem.
  • Check if a proper keyboard shortcut is mapped to the action in gnome-keybinding-properties. A working shortcut looks like XF86AudioMute or Ctrl+Alt+Tab. An unknown key mapping looks like 0xed.

  • For audio hotkey problems see which mixer device and which mixer tracks are set as default in gnome-audio-properties. The volume step can be changed in /apps/gnome_settings_daemon/volume_step with gconf-editor.


CategoryDebugging

Hotkeys/Troubleshooting (last edited 2016-08-02 09:25:51 by penalvch)