Here are some troubleshooting tips that will make it easier to find a
source package. Please attach the results of this as it will allow us to
narrow down the "culprit" package.
1. If gnome-settings-daemon is running, stop it using killall gnome-
settings-daemon. These daemons grab some X events and keep them from
being seen by xev.
2. Run xev to test if a keypress event is seen:
xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode
\2 = \3, state = \1/p'
3. If a keypress is seen (which should be true in your case):
A. If the keycode is right, it's a desktop issue; see the list of packages
that act on hotkey events (e.g. gnome-settings-daemon, gnome-power-manager)
- In some cases the keybinds may be wrong because of a legacy keymap. Check
the keymap using gconf-editor and looking under
/apps/gnome_settings_daemon/keybindings. Keybinds that don"t have sensible
names are probably bugs and should be mentioned.
- For audio issues look at gnome-sound-properties
B. If there are too many keypress events you need to find where they
are being duplicated.
4. If the keycode is wrong (This is likely your problem), or there is no
keypress event, or the key gets stuck after one use, look to the "Fixing Broken
Keys" section in /usr/share/doc/udev/README.keymap.txt.
A. If this is successful file a bug against udev ("ubuntu-bug udev") and
attach the new keymap and rule.
B. If udev's keymap tool shows a correct key symbol, look up the
symbolic name in /usr/include/linux/input.h. If it's mapped to a value
over 255 (over 0x0ff), then see bug 313514. If it's an important key,
remap it to a value < 256.
5. If events are reported by more than one input device, then file a bug
against the "linux" package, because it should only send the event on
one device.
6. If not found using 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, this is a bug in the kernel, for not
translating the ACPI event to an input event.
B. If there is neither an ACPI event or an input event, this is
probably also a kernel bug, but one that is harder to diagnose (I'd
guess WMI)
Information that must be attached individually to your report:
- udevadm info --export-db > udev-db.txt
- dmesg > dmesg.log
- sudo lsinput > lsinput.log
- You must install input-utils in order to do this
- xkbcomp -xkb : 0 - > xkbcomp.txt
- setxkbmap -print > xkbmap.txt
Some additional tips:
Make a list of all keys and functions, make sure they work, test this
after each change you make.
Run gnome-power-manager in verbose (gnome-power-manger --no-daemon
--verbose) to get debug info.
Check hal to see if hotkeys are being listened for as dbus events. Use
lshal -m to check this.
You may want to look at /etc/acpi/ as it is sometimes relevant, but is
being phased out.
Switch in and out of a virtual terminal (e.g. ctrl+alt+F1 ; ctrl+alt+F7)
Check for invalid shortcuts in gnome-keybinding-properties. A working
shortcut would be Ctrl+Alt+Tab, a nonfunctional one would be 0xed.
Sorry this is so long, but keybinds are complicated to be trying to
debug. So if you can collect the information needed and attach it to the
report, I'm sure this can be resolved.
If you have any questions, feel free to contact me
~qbalazs
** Changed in: ubuntu
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1211346
Title:
Key mapping changed after update
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1211346/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
