Created attachment 65926 [details]
"evemu-record" output containing at least a single key press for each button

from the device: 
    Event code 256 (BTN_0)
    Event code 257 (BTN_1)
    Event code 258 (BTN_2)
    Event code 259 (BTN_3)
    Event code 260 (BTN_4)

So this device really just advertises 5 buttons without any semantic meaning. If you want those to be more semantic, you'd have to fix the kernel to assign the keycodes to it.

It is not feasible to modify the kernel for every such device, you will surely agree.

At the very least, can these buttons, semantics meaning notwithstanding, be mapped to "keyboard" key presses rather than mouse ones? One approach is to may be add a configurable option to evdev to force the device type.

There's also an issue of why this device is being recognized as mouse in the first place? It is not a mouse, it has no axis, etc. That's why I asked whether it's feasible to introduce a new device class for such devices, which is neither keyboard nor mouse.

(In reply to comment #3)
> It is not feasible to modify the kernel for every such device, you will surely
> agree.

it is a surprising amount of work to get this done in X as well, and even if it could be done, it'd still be the wrong place in the stack to do it. see below.
 
> At the very least, can these buttons, semantics meaning notwithstanding, be
> mapped to "keyboard" key presses rather than mouse ones? One approach is to may
> be add a configurable option to evdev to force the device type.
> 
> There's also an issue of why this device is being recognized as mouse in the
> first place? It is not a mouse, it has no axis, etc. That's why I asked whether
> it's feasible to introduce a new device class for such devices, which is
> neither keyboard nor mouse.

X only knows about two types of devices, pointer devices (buttons and/or axes) and keyboards. This device has buttons, hence the initialisation as pointer device.

To get the device initialised as keyboard device, you need to modify the driver to skip the button init process but instead set up a full keyboard device. Then you'll need to re-map the buttons into keycodes on the fly. Evdev is already quite a messy codebase, adding this would only make it worse.

Besides, I really think that if you need a generic solution for this (instead of just for one device) then that solution must be in the client stack, not in the driver where it's hidden from everything and doesn't expose the necessary reconfigurability. What you really need is integration into e.g. GNOME so that you can assign a function to a button on a specific device, and GNOME will handle the required actions. It already does so for Wacom tablets' buttons, so extending this to other devices seems like the right choice.

My thinking was exactly about creating an option in xorg.conf to the tune of:

Option "KeyMapping" "<key code> <key code>"

The idea is to force the device into keyboard mode and create a mapping with the set of key codes specified.

At the very least, various user utilities can work with arbitrary key mappings but almost nobody supports arbitrary mouse button mappings.

Not to mention the sorry fact that connecting such device to a computer _immediately_ starts causing annoying, undesired behavior (assuming, not everybody uses gnome and gnome apps - I, for one, rely on quite a few "non-DE" ones). Mapping some loose buttons to first 3 mouse buttons by default is almost the worst default behavior one can expect.

If you don't feel like doing it I can try to tinker with it myself, but would you be willing to accept such a solution into the xorg tree?

(In reply to comment #5)
> My thinking was exactly about creating an option in xorg.conf to the tune of:
> 
> Option "KeyMapping" "<key code> <key code>"
> 
> The idea is to force the device into keyboard mode and create a mapping with
> the set of key codes specified.

IIRC we actually had something similar in evdev 1.2 or so and ripped it out because it was too complex.
 
> At the very least, various user utilities can work with arbitrary key mappings
> but almost nobody supports arbitrary mouse button mappings.

Fix the tools? We can't keep putting kludges into X drivers to save tool developers from doing the right thing.

> Not to mention the sorry fact that connecting such device to a computer
> _immediately_ starts causing annoying, undesired behavior (assuming, not
> everybody uses gnome and gnome apps - I, for one, rely on quite a few "non-DE"
> ones). Mapping some loose buttons to first 3 mouse buttons by default is almost
> the worst default behavior one can expect.

Option "ButtonMapping" already exists, so you can shift this to higher logical buttons to avoid immediate interference.

> If you don't feel like doing it I can try to tinker with it myself, but would
> you be willing to accept such a solution into the xorg tree?

tbh, it's unlikely, sorry. We have too many kludges already, some of which even conflict with each other. All put into the drivers because that was the easy thing to do. Now it's largely causing pain. Updating the driver already is a dance between fixing bugs while not breaking everything around.

Ok, I see.

Because evdev is considered somehow too complex (and it's not even that bigger than old school mouse_drv, not to mention beasts like synaptics), all the apps relying on customizable hotkeys (including closed source legacy ones) now have to be rewritten to support XI2 style floating devices. Great idea.

And, of course, whoever had some hopes to use one of the untold scores of usb or bluetooth devices, which behave that way, properly under linux, are now welcome to return to their beloved windows installations. :-)

I'm coming from the "windows" world and trying to see if there is something that Plantronics can do differently to avoid this mis-mapping issue. From my standpoint, the buttons are listed under "vendor-unique", 0xFFA0 in the report descriptor. Since they are vendor unique and not explicitly described, would it be possible to not map the buttons? It seems like ignoring a button without an explicit description would be a robust solution.

I'm not looking at the .648 as was mentioned, but I'm seeing the same problem on currently shipping PLT headsets.

thx,
rob

> From my standpoint, the buttons are listed under "vendor-unique",
> 0xFFA0 in the report descriptor. Since they are vendor unique and not
> explicitly described, would it be possible to not map the buttons?

Such mapping can be done by, eg, udev.

On my (gentoo) box, the directory /lib/udev/keymaps/ contains device-
specific keymaps.  On other distros that might be in /usr/lib/.

As one example, the file /lib/udev/keymaps/logitech-wave includes a
mapping:

  0x9003D prog1 #gadget

which says that 0x9003D, which is sent by the key marked gadget, instead
should generate the <linux/include.h> keysym KEY_PROG1, which xf86-input-evdev
and xkb convert to the X11 keysym XF86Launch1.

I have built a special xorg.conf patch for preventing the Plantronics USB headsets to send core events that would capture the actual mouse buttons events.

Here is what my .conf contains:

Section "InputClass"
  Identifier    "PLTUSBHeadsetsNoCoreEvents"
  MatchVendor   "Plantronics"
  Option        "SendCoreEvents" "off"
EndSection

I used "SendCoreEvents" for it is known from older distros too.

This works in Ubuntu 12.04: http://www.helplinux.ru/wiki/en:kb:ubuntu-plantronics

closing as WONTFIX, this won't be fixed in the evdev driver. Please see the solution Stanislav linked to in comment 11 for a workaround (well, it's almost the proper solution)

Stanislav: I recommend adding this mapping to the systemd/udev hwdb so it is upstreamed. I suspect something like this should do

$> cat /etc/udev/hwdb.d/99-plantronics-headset.hwdb
keyboard:usb:v47fpc013*
  KEYBOARD_KEY_FFA000B1=volumeup
  and the other keys here

I took the FFA000B1 from your link, use showkeys -s to get the scancode for each key.

Peter,

I've added hwdb variant to the page.
BTW: "showkeys" -s doesn't work for this device.