X-Tension XK-200 Multimedia Keyboard: Media Player key wrong

[Dominik Kubla]

I would like to sumit the necessary information to recognize and support the X-Tension XK-200 wireless multimedia keyboard/mouse (and possibly others since it appears to be a OEM device).

lsusb output:

Bus 001 Device 003: ID 062a:0102 Creative Labs
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 1.10
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x062a Creative Labs
  idProduct 0x0102
  bcdDevice 1.00
  iManufacturer 1 MOSART Semi.
  iProduct 2 Wireless Keyboard & Mouse
  iSerial 0
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 59
    bNumInterfaces 2
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower 100mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 3 Human Interface Devices
      bInterfaceSubClass 1 Boot Interface Subclass
      bInterfaceProtocol 1 Keyboard
      iInterface 0
        HID Device Descriptor:
          bLength 9
          bDescriptorType 33
          bcdHID 1.10
          bCountryCode 0 Not supported
          bNumDescriptors 1
          bDescriptorType 34 Report
          wDescriptorLength 65
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0008 1x 8 bytes
        bInterval 10
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 1
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 3 Human Interface Devices
      bInterfaceSubClass 1 Boot Interface Subclass
      bInterfaceProtocol 2 Mouse
      iInterface 0
        HID Device Descriptor:
          bLength 9
          bDescriptorType 33
          bcdHID 1.10
          bCountryCode 0 Not supported
          bNumDescriptors 1
          bDescriptorType 34 Report
          wDescriptorLength 181
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0005 1x 5 bytes
        bInterval 10
Device Status: 0x0000
  (Bus Powered)

Recommended key mapping for the device:

keycode 122 = XF86Search
keycode 129 = XF86Music
keycode 130 = XF86HomePage
keycode 144 = XF86AudioPrev
keycode 153 = XF86AudioNext
keycode 160 = XF86AudioMute
keycode 161 = XF86Calculator
keycode 162 = XF86AudioPlay
keycode 164 = XF86AudioStop
keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume
keycode 178 = XF86WWW
keycode 198 = XF86MyComputer
keycode 223 = XF86Standby
keycode 230 = XF86Favorites
keycode 231 = XF86Refresh
keycode 232 = XF86Stop
keycode 233 = XF86Forward
keycode 234 = XF86Back
keycode 236 = XF86Mail

It should be mentioned that in Kubuntu Feisty the following special keys appear not to be mapped to functions or preferred applications:

XF86Favourites
XF86Standby
XF86WWW (works partially: selects home page when focussed on konqueror. should start a web browser window in any other case)

ProblemType: Bug
Architecture: i386
Date: Wed Mar 21 10:56:47 2007
DistroRelease: Ubuntu 7.04
Uname: Linux duron.intern.kubla.de 2.6.20-12-generic #2 SMP Sun Mar 18 03:07:14 UTC 2007 i686 GNU/Linux

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in recently. We were wondering if this is still and issue for you? Thanks in advance.

[Dominik Kubla (dbkubla)]

Am Dienstag 04 Dezember 2007 schrieb Brian Murray:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in recently. We were wondering if this is still and issue
> for you? Thanks in advance.
>
> ** Changed in: ubuntu
> Assignee: (unassigned) => Brian Murray (brian-murray)
> Status: New => Incomplete

Hi Brian,

I suppose this is still an issue, since:
* I always have to load my .Xmodmap file to activate the extra keys.
* There is no profile for Kubuntu to use the multi-media keys consistently.

BTW.
* The "Windows" and "Menu" keys are mapped to modifiers, but they are also not
used consistently throughout.

Is there a usability team for *ubuntu?

Regards,
  Dominik

--
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.

[miner49er (matholton)]

I know this isn't the place to ask but I was wondering if the original poster had managed to get the ouse working for this keyboard/mouse set - it doesn't work on mine.

[Martin Pitt (pitti)]

Sorry for the long delay. I'll take care of this ASAP.

For this to proceed, can you please attach the keyboard, do "lshal > /tmp/hal.txt" and attach it here?

How did you determine the keycodes? For hal-info, we need scancodes, as input-events (in the input-utils) package outputs them.

Thank you!

[Dominik Kubla (dbkubla)]

Martin,

sorry for not getting back to you. I have since replaced this keyboard with a wired one, but still own it. I'll connect it again and provide you with the necessary information, but this will take some days.

Thanks for taking care...
  Dominik

[Dominik Kubla (dbkubla)]

Martin,

I attached the keyboard to my workstation. It was recognized correctly but somehow configured wrong (Shift key had no function and some other oddities), so I could not use it. I'll try again and give you the desired output.

To answer your question how I determined the key codes: I ran xev and pressed all keys one by one. :-)

Cheers,
  Dominik

[Martin Pitt (pitti)]

Indeed, xev won't help a lot if the keyboard's scan codes aren't recognized correctly. Can you please follow https://wiki.ubuntu.com/Hotkeys/Troubleshooting, in particular the bit about input-events showing the scan codes?

[Dominik Kubla (dbkubla)]

It appears to be that my keyboard is broken: It show the same behaviour on Windows Vista.

In any case the configuration appears to be correct, but my original keycode list had an error: keycode 179 should be mapped to XF86Music, not keycode 129.

Good news is that everything else works as expected. Great job!

For completeness here are the debug outputs as recommended by the troubleshooting guide:

[Martin Pitt (pitti)]

Dominik,

thanks for checking this again. I'm still unclear about the current status, though: Are you saying that in Jaunty (Ubuntu 9.04) everything works out of the box, or that it would work once you manually set the keymap from above?

Thanks!

[Dominik Kubla (dbkubla)]

Martin,

except for the "Media Player" key being mapped to XF86Tools instead of XF86Music everything works out of the box.
All function keys, the scroll wheels (both mouse and keyboard) and all mouse buttons are recognized and work.

Cheers,
  Dominik

[Martin Pitt (pitti)]

Sorry for bothering you some more. The handling of keymaps changed recently, and since this is an external keyboard, the usual system vendor/product match does not work. I need to write a custom udev rule for this external keyboard.

Can you please attach /var/log/udev?

[Dominik Kubla (dbkubla)]

No problem and sorry about the delay.

[Martin Pitt (pitti)]

Dominik, thanks for the udev log. However, you still didn't tell me the scan code of the key which is wrong. (See comment 7).

On current karmic, you can use "sudo /lib/udev/keymap -i input/event3" to figure out the scan code. (See /usr/share/doc/udev-extras/README.keymap.txt).

If you want to do this on jaunty, please see http://martinpitt.wordpress.com/2009/05/08/devicekit-update-future-handling-of-fn-key-maps/ for instructions how to install the new udev-extras on jaunty. This isn't strictly required for finding the scan code, but you are going to need it for testing my fix.

Thanks!

[Dominik Kubla (dbkubla)]

Martin,

I tried "/lib/udev/keymap -i input/event3", but I don't get a keycode
displayed for the multimedia keys. Not even for those that do work as
expected.

Cheers,
  Dominik

[Martin Pitt (pitti)]

Dominik,

seems these keys are on a different input device then. Can you please just try all from input/event1 to input/event5? (it's most likely 4 then)

[Dominik Kubla (dbkubla)]

On Mi, 2009-06-24 at 06:06 +0000, Martin Pitt wrote:
> Dominik,
>
> seems these keys are on a different input device then. Can you please
> just try all from input/event1 to input/event5? (it's most likely 4
> then)
>

Yes, they were reported via the second event channel:

scan code: 0xC00B7 key code: stopcd
scan code: 0xC00E2 key code: min_interesting <--- This is the mute key
scan code: 0xC0183 key code: config <--- This is the media player key
scan code: 0xC018A key code: mail
scan code: 0xC0227 key code: refresh
scan code: 0xC0226 key code: stop
scan code: 0xC0223 key code: homepage
scan code: 0xC0225 key code: forward
scan code: 0xC0224 key code: back
scan code: 0xC0221 key code: search
scan code: 0xC022A key code: bookmarks
scan code: 0x10082 key code: sleep
scan code: 0xC0194 key code: file
scan code: 0xC0192 key code: calc
scan code: 0xC00EA key code: volumedown
scan code: 0xC00E9 key code: volumeup
scan code: 0xC00B5 key code: nextsong
scan code: 0xC00B6 key code: previoussong
scan code: 0xC00CD key code: playpause

Cheers,
  Dominik

[Martin Pitt (pitti)]

Ugh, seems that input event enumeration changes severely with every reboot. In the attached udev log and lsinput, event2 is the mouse. Can you please attach lsinput output and then check with /lib/udev/keymap which device outputs these keys in the same session, i. e. without rebooting in between?

Sorry that this takes so long, it is the first case which we fix which involves an external USB keyboard. Thanks for bearing with me!

[Dominik Kubla (dbkubla)]

On Mo, 2009-06-29 at 10:57 +0000, Martin Pitt wrote:
> Ugh, seems that input event enumeration changes severely with every
> reboot. In the attached udev log and lsinput, event2 is the mouse. Can
> you please attach lsinput output and then check with /lib/udev/keymap
> which device outputs these keys in the same session, i. e. without
> rebooting in between?
>
> Sorry that this takes so long, it is the first case which we fix which
> involves an external USB keyboard. Thanks for bearing with me!
>

It changed because I unplugged my normal keyboard and attached this one.
Now I have booted with both keyboards attached.

The special keys show up on input/event7.

[Martin Pitt (pitti)]

OK, I have a tentative fix for this. In current Karmic (daily live system) or Jaunty with my PPA's udev-extras (see http://martinpitt.wordpress.com/2009/05/08/devicekit-update-future-handling-of-fn-key-maps/), please apply the attached patch with

  sudo patch /lib/udev/rules.d/95-keymap.rules keymap.patch

and drop the other attachment (usb-mosart-0102) into /lib/udev/keymaps/. Then reboot, and check if the mute and media player keys are working then.

Thank you!

[Martin Pitt (pitti)]

sudo cp usb-mosart-0102 /lib/udev/keymaps/

[Dominik Kubla (dbkubla)]

Hi Martin,

the mute key now works, but the media key still returns "config" which
is translated to "XF86Tools":

dominik@scaleo:~$ sudo /lib/udev/keymap -i input/event7
Press ESC to finish
scan code: 0xC0183 key code: config
scan code: 0xC0183 key code: config

Cheers,
  Dominik

[Martin Pitt (pitti)]

Hello Dominik,

ok, so it seems that something in the chain doesn't like the extraordinarily high scan code. Could you please do

  sudo strace -fvvo /tmp/keymap.trace /lib/udev/keymap input/event7 usb-mosart-0102

and then attach /tmp/keymap.trace here?

Thanks!

[Dominik Kubla (dbkubla)]

Am Dienstag, den 28.07.2009, 18:56 +0000 schrieb Martin Pitt:
> Hello Dominik,
>
> ok, so it seems that something in the chain doesn't like the
> extraordinarily high scan code. Could you please do
>
> sudo strace -fvvo /tmp/keymap.trace /lib/udev/keymap input/event7 usb-
> mosart-0102
>
> and then attach /tmp/keymap.trace here?
>
> Thanks!
>

It seems to me that we are trying to load the keycode on the wrong input
device. If I use the first one (event7) I get EVIOCGKEYCODE (see
keymap.trace), if I use the second one (event8) it works (see
keymap.trace2)

Cheers,
  Dominik

[Martin Pitt (pitti)]

Argh, it would help if I wouldn't make typos in rules. Sorry for that!

Can you please try

  sudo gedit /lib/udev/rules.d/95-keymap.rules

and in this line

  ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102", ID_CLASS="kbd" RUN=+"keymap $name usb-mosart-0102"

add the missing comma after the "kbd" ? I. e. replace the line with

  ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102", ID_CLASS="kbd", RUN=+"keymap $name usb-mosart-0102"

Does it work now?

Thanks!

[Martin Pitt (pitti)]

Oops, another typo, it needs to be ID_CLASS==. Please replace the line with

  ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102", ID_CLASS=="kbd", RUN=+"keymap $name usb-mosart-0102"

Now for real!

[Dominik Kubla (dbkubla)]

Am Sonntag, den 02.08.2009, 15:34 +0000 schrieb Martin Pitt:
> Oops, another typo, it needs to be ID_CLASS==. Please replace the line
> with
>
> ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102",
> ID_CLASS=="kbd", RUN=+"keymap $name usb-mosart-0102"
>
> Now for real!
>

No luck. If I run the kbd command manually it works. I still think we
are trying to redefine on the wrong input device...

Is there a way to trace the whole sequence done during boot-up?

Dominik

[Martin Pitt (pitti)]

> Is there a way to trace the whole sequence done during boot-up?

Something like this. "udevadm test /devices/.../" (the sysfs path) will show the matches and commands run.

Unfortunately the original lsinput/ udev dump logs don't match your current USB setup any more (event7/event8), so I had to guess. But the only other "MOSART" device is the "mouse" part of that device, so I guessed it wouldn't be that. Just to cover all cases, does this work?

   ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102", ID_CLASS=="mouse", RUN=+"keymap $name usb-mosart-0102"

if not, does this?

ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102", RUN=+"keymap $name usb-mosart-0102"

BTW, you don't really need to reboot after changing the rule. Either just unplug/replug the keyboard, or do

  sudo udevadm trigger --subsystem-match=input

[Martin Pitt (pitti)]

Also, to get current data on this, can you please give me the output of these commands:

  udevadm info --query=all --name=/dev/input/event7
  udevadm info --attribute-walk --name=/dev/input/event7
  udevadm info --query=all --name=/dev/input/event8
  udevadm info --attribute-walk --name=/dev/input/event8

(assuming that the two devices in question are 7 and 8 at the moment). Thanks!

[Dominik Kubla (dbkubla)]

Am Sonntag, den 02.08.2009, 20:56 +0000 schrieb Martin Pitt:
> > Is there a way to trace the whole sequence done during boot-up?
>
> Something like this. "udevadm test /devices/.../" (the sysfs path) will
> show the matches and commands run.

# udevadm
test /devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.1/input/input7
run_command: calling: test
udevadm_test: version 145
This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
...
parse_file: reading '/lib/udev/rules.d/95-keymap.rules' as rules file
add_rule: unknown key 'ID_CLASS' in /lib/udev/rules.d/95-keymap.rules:14
...

Line 14 of 95-keymap.rules is:

ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102",
ID_CLASS=="kbd", RUN=+"keymap $name usb-mosart-0102"

After modifying it to:

ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102",
ENV{ID_CLASS}=="kbd", RUN=+"keymap $name usb-mosart-0102"

The udevadm output looks better. But still no luck.

Cheers,
  Dominik

[Dominik Kubla (dbkubla)]

Am Sonntag, den 02.08.2009, 20:59 +0000 schrieb Martin Pitt:
> Also, to get current data on this, can you please give me the output of
> these commands:
>
> udevadm info --query=all --name=/dev/input/event7
> udevadm info --attribute-walk --name=/dev/input/event7
> udevadm info --query=all --name=/dev/input/event8
> udevadm info --attribute-walk --name=/dev/input/event8
>
> (assuming that the two devices in question are 7 and 8 at the moment).
> Thanks!
>

The device number depends on whether the wireless keyboard is connected
at boot time. If it is they are 6+7, otherwise 7+8.

Here is the output as requested.

Cheers,
  Dominik

[Martin Pitt (pitti)]

So does it work with

ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102", ENV{ID_CLASS}=="mouse", RUN=+"keymap $name usb-mosart-0102"

?

[Dominik Kubla (dbkubla)]

On Monday 03 August 2009 22:37:42 Martin Pitt wrote:
> So does it work with
>
> ENV{ID_VENDOR}=="MOSART_Semi.", ENV{ID_MODEL_ID}=="0102",
> ENV{ID_CLASS}=="mouse", RUN=+"keymap $name usb-mosart-0102"
>
> ?

Hi Martin,

sorry about the delay.

Unfortunately this does not solve the problem. xev still reports the key as
XF86Tools.

Everything else works just fine. Since I have already replaced the keyboard for
daily work and no one else has come forward owning one of these, closing the
bug at this stage is fine from my point of view.

Many thanks for your efforts!
  Dominik

[Martin Pitt (pitti)]

OK, if you don't have the keyboard any more, I guess it's too hard to get the debugging data out of it. Thanks for your patience anyway!