# evdev thinks my headset is a mouse, goes crazy.

## Hexorg

Good daytime to you all. 

evdev is behaving strange for me this time. I just installed a fresh system, and I was in the process of setting everything up, as my mouse start to behave wierd - left-clicking on windows would not work, unless you right click on a window that had a focus before that. 

Trying to investigate, I stumbled upon this xorg log:

```
[     6.337] (II) config/udev: Adding input device Logitech Logitech G930 Headset (/dev/input/event2)

[     6.337] (**) Logitech Logitech G930 Headset: Applying InputClass "evdev keyboard catchall"

[     6.337] (II) Using input driver 'evdev' for 'Logitech Logitech G930 Headset'

[     6.337] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so

[     6.337] (**) Logitech Logitech G930 Headset: always reports core events

[     6.337] (**) Logitech Logitech G930 Headset: Device: "/dev/input/event2"

[     6.337] (--) Logitech Logitech G930 Headset: Found 14 mouse buttons

[     6.337] (--) Logitech Logitech G930 Headset: Found keys

[     6.337] (II) Logitech Logitech G930 Headset: Configuring as mouse

[     6.337] (II) Logitech Logitech G930 Headset: Configuring as keyboard

[     6.337] (**) Logitech Logitech G930 Headset: YAxisMapping: buttons 4 and 5

[     6.337] (**) Logitech Logitech G930 Headset: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200

[     6.337] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.3/input/input2/event2"

[     6.337] (II) XINPUT: Adding extended input device "Logitech Logitech G930 Headset" (type: KEYBOARD, id 8)

[     6.337] (**) Option "xkb_rules" "evdev"

[     6.337] (**) Option "xkb_model" "evdev"

[     6.337] (**) Option "xkb_layout" "us"
```

The headset is USB and it does have a volume knob + 3 media keys... But a 14 buttoned mouse?! O_O

Anyway, after disconnecting the headset, mouse started working perfectly. Unfortunately I'm unfamiliar with udev rules syntax and don't know where to start. Is there a way to either show udev that this is a headset and not a mouse, or just make it completly ignore this device's buttons while still allowing alsa to use it as a sound output device?

----------

Useful info:

Xorg version 1.11.4

evdev module version = 2.6.0

Headset audio work fine no matter what evdev does.

gcc version 4.5.3

Linux kernel 3.2.12-gentoo

----------

## audiodef

Someone much more familiar with evdev and udev than I can give you advice on how to tweak this, but the first thing I thought of was replacing evdev with the keyboard and mouse drivers, which I imagine would keep your keyboard and mouse working while bypassing evdev's claim on the headset (since evdev wouldn't be running).

----------

## VoidMage

First, lets make sure it's really udev, that's misbehaving.

What does 'udevadm info' print about that headset ?

----------

## Fitzcarraldo

I may be wide of the mark here, but I had what appears to be a somewhat similar case a few years ago. In my case I was trying to get a DVB-T USB stick (Afa Technologies Inc. AF9035A USB Device) working. Notice in the output from dmesg posted below that the usbhid driver incorrectly thought that my DVB-T stick was a keyboard:

```
[  824.549123] generic-usb 0003:15A4:1001.0001: input,hidraw0: USB HID v1.01 Keyboard [Afa Technologies Inc. AF9035A USB Device] on usb-0000:00:1d.7-4/input1
```

It was necessary to stop the usbhid driver from doing this, because the DVB-T stick certainly isn't a keyboard.

Now, if the usbhid driver is a kernel module (CONFIG_USB_HID=m in the kernel config) then the way to tell the usbhid driver to ignore this specific device, as it has its own driver, would be to pass an option to the usbhid driver by putting the following line in the file /etc/modprobe.d/usbhid.conf

```
options usbhid quirks=0x15a4:0x1001:0x0004
```

where 0x15a4 is the Vendor ID and 0x1001 is the Product ID, both obtained by looking at the output of either the dmesg or lsusb commands, and the 0x0004 flag is HID_QUIRK_IGNORE, which tells the usbhid driver to ignore the device.

However, in the case of my kernel the usbhid driver was not a module, it was built into the kernel (CONFIG_USB_HID=y in the kernel config), so the way to tell the usbhid driver to ignore this specific device, as it has its own driver, would be to pass the option to the usbhid as a boot parameter, by editing /boot/grub/grub.conf and adding the following boot parameter to the end of the kernel boot line:

```
usbhid.quirks=0x15a4:0x1001:0x0004
```

Then when I rebooted I saw the following for the DVB-T stick in the dmesg output:

```
[  196.322403] usb 1-1.4: new high speed USB device using ehci_hcd and address 13

[  196.414896] usb 1-1.4: New USB device found, idVendor=15a4, idProduct=1001

[  196.414903] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[  196.414909] usb 1-1.4: Product: AF9035A USB Device

[  196.414913] usb 1-1.4: Manufacturer: Afa Technologies Inc.

[  196.414917] usb 1-1.4: SerialNumber: AF0102020700001

[  196.415183] usb 1-1.4: configuration #1 chosen from 1 choice
```

Compare the new dmesg output above with the old dmesg output at the top of this post. You can see that the usbhid driver now ignores the DVB-T stick and it is no longer listed as a keyboard.

So it might be that you may need to do something along similar lines. As I say, I could be wide of the mark, but thought I'd mention it just in case.

----------

