[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#706874: keyboard-configuration: Support for gaming keyboards (macro keys, mode switches, more than 127 keys)




Package: keyboard-configuration
Version: 1.88
Severity: wishlist

   * What led up to the situation?

I purchased a Corsair Vengeance K90 Keyboard, expecting to be able to
configure a keyboard model/layout for it. So far I have been
frustrated.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I attempted to use xev, then showkeys -s, to learn the scancodes for
the additional keys (18 macro keys, a macro record button, and three
macro 'mode switch' buttons that are used (in the Win driver anyway)
to toggle between different macro profiles).  It was my intent to then
use autokeys or similar to have a nice set of macros without stomping
on standard keyboard shortcuts or rendering half the functionality of
emacs unusable. (Emacs uses many key combos that often get tied to
shortcuts and thus grabbed from the input before emacs has a chance to
see them).

   * What was the outcome of this action?

xev reports mappable scancodes for only some of these items; the rest
are 'silent' as far as it can tell.  showkeys -s reports scancodes for
all keys, but _identical_ scancodes for most of the macro keys.  On
further investigation I discovered that the keyboard shows up with
several different USB id's.  Specifically...


bear@excessive:/etc/X11/xkb$ ls -la /dev/input/by-id
total 0
drwxr-xr-x 2 root root 160 Apr 27 08:13 .
drwxr-xr-x 4 root root 440 Apr 27 08:13 ..
lrwxrwxrwx 1 root root   9 Apr 27 08:13
usb-Corsair_Corsair_Vengeance_K90_Keyboard-event-if01 -> ../event2
lrwxrwxrwx 1 root root   9 Apr 27 08:13
usb-Corsair_Corsair_Vengeance_K90_Keyboard-event-kbd -> ../event1
lrwxrwxrwx 1 root root   9 Apr 27 08:13
usb-Corsair_Corsair_Vengeance_K90_Keyboard-if02-event-kbd -> ../event3
lrwxrwxrwx 1 root root   9 Apr 27 08:13
usb-Kensington_Kensington_Expert_Mouse-event-mouse -> ../event0
lrwxrwxrwx 1 root root   9 Apr 27 08:13
usb-Kensington_Kensington_Expert_Mouse-mouse -> ../mouse0
lrwxrwxrwx 1 root root   9 Apr 27 08:13
usb-Wacom_Co._Ltd._MTE-450-mouse -> ../mouse1



bear@excessive:~$ xinput --list
⎡ Virtual core pointer            id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer  id=4    [slave pointer   (2)]
⎜   ↳ Wacom Bamboo stylus         id=8    [slave pointer   (2)]
⎜   ↳ Kensington Expert Mouse     id=9    [slave pointer   (2)]
⎜   ↳ Corsair Vengeance K90       id=11   [slave pointer   (2)]
⎜   ↳ Wacom Bamboo eraser         id=14   [slave pointer   (2)]
⎜   ↳ Wacom Bamboo cursor         id=15   [slave pointer   (2)]
⎜   ↳ Wacom Bamboo pad            id=16   [slave pointer   (2)]
⎣ Virtual core keyboard           id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5    [slave keyboard (3)]
    ↳ Power Button                id=6    [slave keyboard (3)]
    ↳ Power Button                id=7    [slave keyboard (3)]
    ↳ Corsair Vengeance K90       id=10   [slave keyboard (3)]
    ↳ Corsair Vengeance K90       id=12   [slave keyboard (3)]
    ↳ Eee PC WMI hotkeys          id=13   [slave keyboard (3)]



(Line wrap made a hash of that, so I edited somewhat).

It's showing up as several different USB devices, with different
events.  So I used xinput to list the properties of each of these
devices.

Id 11 is apparently how the keyboard can send pointer events while
playing back macros.  id 10 appears to be the primary keyboard,
roughly equivalent to pc105 plus minimal multimedia keys
(play/stop/next/last/volume knob).  The macro mode switch buttons and
macro record buttons also show up on this device.  The G-keys (macro
keys) create events here, but are mostly mapped to the same
keystroke, which has no symbolic keycode mapped to it.

Id 12 is apparently the macro keypad itself.  While id 11 shows the
same scancode for most of these keys, id 12 shows different scancodes
for these keys.  (I monitored it with a 'hacked' version of showkeys
so I could look at individual devices instead of just defaulting to
the 'standard' keyboard).

So, all right, it's complex and there are more than 127 keys so
they're using an additional usb 'device'.  At this point I thought I
had enough information to go and write a keyboard model that would map
all the keystrokes to scancodes, and help expand the keyboard database
... but as far as I can tell, it appears that xkb cannot be configured
to use information from more than one 'device' to decode keystrokes.
At the very least, if it can, then no one has discovered and
documented how to describe such a device to it.

Furthermore, there appear to be no keycodes in
/usr/include/linux/input.h for G-keys/macro keys, for a dedicated
macro-record button, or for macro mode switches or profile-switch
buttons, so even if it turns out that there is a way I can write a
description for the keyboard model, I would have to make up stuff and
tie it to codes that someone else would unfortunately be using for
something else.

G-keys, or macro keys, are widely implemented on gaming keyboards;
there are scores, possibly hundreds, of keyboard models that have
additional keys for macros, and for controlling the recording of
macros, that are widely used by gamers.  Macro mode switches are
implemented on many gaming keyboards and, as profile or layout switch
buttons, on both gaming and international keyboards.

It's therefore upsetting that there is no standard set of scancodes
for them, and this should be addressed. Certainly they are more common
than force-feedback equipment which does appear to be fully supported.


   * What outcome did you expect instead?

I hoped, once I knew what the keystrokes were sending and on which USB
devices, to be able to describe the keyboard to xkb and then use
autokey or similar to make the macro stuff work.

I don't expect you guys to write support for a keyboard that is as
rare as the Corsair Vengeance K90. Heck, I'll do that, if I can figure
out how. The effort is not justified in order to serve a "larger community" so much as it is for my own convenience. But the K90 has features in common with several other high-end keyboards (macro keys, macro recording button, mode switch keys, and more than one USB id/ more than 127 keys), and those features ought to be supported in a general way that at least allows such things to be described to xkb.

More information (and code that gets some minimal functionality from
a K90 by doing an end run past xkb and the linux driver) is available at:

https://github.com/jupiter126/Linux_Custom_Control_Device

Full disclosure: I am not the author of the code at the above github
repository; it was written by someone else dealing with the same
problem and showed up when I was searching for resources.

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages keyboard-configuration depends on:
ii  debconf                 1.5.49
ii  initscripts             2.88dsf-41
ii  liblocale-gettext-perl  1.05-7+b1

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages console-setup depends on:
ii  console-setup-linux  1.88
ii  debconf              1.5.49
ii  xkb-data             2.5.1-3

Versions of packages console-setup suggests:
ii  locales   2.13-38
ii  lsb-base  4.1+Debian8

Versions of packages console-setup-linux depends on:
ii  console-tools  1:0.2.3dbs-70

Versions of packages console-setup-linux suggests:
ii  console-setup  1.88

Versions of packages keyboard-configuration is related to:
ii  console-common  0.7.87
ii  console-data    2:1.12-2
ii  console-tools   1:0.2.3dbs-70
pn  kbd             <none>


-- debconf information:
console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages
* keyboard-configuration/layout:
* keyboard-configuration/xkb-keymap: us
* keyboard-configuration/variant: English (US)
  debian-installer/console-setup-udeb/title:
  keyboard-configuration/unsupported_options: true
  console-setup/framebuffer_only:
  keyboard-configuration/ctrl_alt_bksp: false
  console-setup/guess_font:
* keyboard-configuration/variantcode:
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/other:
* keyboard-configuration/optionscode:
  console-setup/use_system_font:
  console-setup/fontsize: 8x16
* keyboard-configuration/modelcode: pc105
  keyboard-configuration/unsupported_config_options: true
  console-setup/fontface47: Fixed
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/toggle: No toggling
  console-setup/fontsize-text47: 8x16
* keyboard-configuration/compose: No compose key
* keyboard-configuration/switch: No temporary switch
  console-setup/charmap47: UTF-8
* keyboard-configuration/altgr: The default for the keyboard layout
  console-setup/codesetcode: Lat15
  keyboard-configuration/unsupported_layout: true
* keyboard-configuration/model: Generic 105-key (Intl) PC
* keyboard-configuration/layoutcode: us
  console-setup/fontsize-fb47: 8x16
* keyboard-configuration/store_defaults_in_debconf_db: true


Reply to: