You are not logged in.
I have the IBM/Lenovo SK-8815 USB extended keyboard and I am having trouble mapping the extra keys in Gnome.
This keyboard has the usual keyboard keys along with a set of multi-media keys (play/stop/prev/next etc.) browser back/forward keys, and a set of seven coloured keys along the top that, under Windows, would usually open specific applications. The built-in label suggests Green="Lock Desktop", Yellow="My Documents", Blue="Word Processor", Red="Spreadsheet", Grey="Calculator", Purple="E-mail", Orange="Internet".
Most of the extended keys do useful things but the coloured keys along the top don't and the gnome-keybinding config does not even seem to notice I am pressing them, except for the first couple which seemed to do weird things.
On further investigation it seems this keyboard is two USB devices, one for the main keys and one for the extended keys and, for the second USB device, X is seeing it as a combined mouse and keyboard and xev is reporting mouse button events for these coloured keys. The picture is further complicated because the first two keys (green and yellow) report as button 2 and button 3 respectively so no doubt the strange behaviour of these two buttons I was seeing is because gnome had actions bound to these mouse buttons. Here is the section from :0.log which shows X detecting this device as a mouse/keyboard combo:
(II) config/udev: Adding input device Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ) (/dev/input/event4)
(**) Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Applying InputClass "evdev keyboard catchall"
(II) Using input driver 'evdev' for 'Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 )'
(**) Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): always reports core events
(**) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Device: "/dev/input/event4"
(--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Vendor 0x4b3 Product 0x301b
(--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Found 12 mouse buttons
(--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Found keys
(II) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Forcing relative x/y axes to exist.
(II) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Configuring as mouse
(II) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Configuring as keyboard
(**) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): YAxisMapping: buttons 4 and 5
(**) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 )" (type: KEYBOARD, id 10)
By comparison a small test program that reads the Linux input device seems to report this as just a keyboard and is happy to give scan codes for the keys concerned. Does anyone have a clue as to what is going on for the detection of this?
Offline
To answer my own question it looks as if, with a keyboard which has unmapped scan codes, the extra keys are mapped to mouse buttons by default. Adding a udev custom keyboard file to map these scan codes to normal keycodes seems to solve the problem. Following instructions in https://wiki.archlinux.org/index.php/Ma … o_keycodes I ended up with a file '/etc/udev/hwdb.d/90-custom-keyboard.hwdb' with the contents:
# IBM/Lenovo SK-8815 Enhanced USB Keyboard
keyboard:usb:v04B3p301B*
KEYBOARD_KEY_90001=setup
KEYBOARD_KEY_90002=prog1
KEYBOARD_KEY_90003=file
KEYBOARD_KEY_90004=prog3
KEYBOARD_KEY_90005=prog4
KEYBOARD_KEY_90006=calc
KEYBOARD_KEY_90007=mail
KEYBOARD_KEY_90008=www
For some of these keys there seemed to be more obvious keycode names but judging by xev it seems X has a problem with codes above 255 and one, the name 'coffee' for the "lock screen" function didn't cause that scancode to be mapped at all - perhaps a difference in the names known to udevadm and those in my /usr/include/linux/input.h
Offline