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

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

Your message dated Thu, 7 Aug 2014 18:52:22 +0300
with message-id <20140807155222.GF15346@debian.lan>
and subject line Re: Bug#706874: keyboard-configuration: Support for gaming keyboards (macro keys, mode switches, more than 127 keys)
has caused the Debian Bug report #706874,
regarding keyboard-configuration: Support for gaming keyboards (macro keys, mode switches, more than 127 keys)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

706874: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706874
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---

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

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

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

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:


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)
  keyboard-configuration/unsupported_options: true
  keyboard-configuration/ctrl_alt_bksp: false
* keyboard-configuration/variantcode:
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/other:
* keyboard-configuration/optionscode:
  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

--- End Message ---
--- Begin Message ---
On Sun, May 05, 2013 at 09:37:12AM -0700, Ray Dillinger wrote:
> 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.
> [...]

Thank you for your bug report.  It has been most informative and I 
learned a great deal from it.  Unfortunately I have to close it because 
it doesn't realy belong to console-setup (or keyboard-configuration) and 
keeping it here helps nothing.  I would reccomend you to report similar 
bug reports to the corresponding upstream maintainers.

Please read the following with caution.  I am not specialist so you 
should expect false statements.

As far as I understand the Linux kernel does not permit more than 127 
different scancodes per one device.  For your particular keyboard this 
is not a problem because it creates separate USB devices.

This means X has to be configured to use two different keyboards 
generating two different sets of scancodes.  I don't know if this is 
possible.  You can try creating a /etc/X11/xorg.conf file where the 
different USB keyboards are described and X is instructed to use them 
directly.  Try something like this:

Section "InputDevice"
        Identifier      "keyboard0"
        Driver          "evdev"
        Option          "Device"                "/dev/input/event1"
        Option "xkb_rules" "evdev"
        Option "xkb_model" "evdev"
        Option "xkb_layout" "us"

Section "InputDevice"
        Identifier      "keyboard1"
        Driver          "evdev"
        Option          "Device"                "/dev/input/event2"

	Option "xkb_keycodes" "vengeance"
	Option "xkb_types" "default"
	Option "xkb_compat" "default"
	Option "xkb_symbols" "vengeance"

Look in /var/log/Xorg.0.log to make sure that X is going to use 
different sets of keycodes for both keyboards. Ofcourse you have to 
create the files


The following page can be helpful:


Anton Zinoviev

--- End Message ---

Reply to: