View previous topic :: View next topic |
Author |
Message |
Hexorg Tux's lil' helper
Joined: 29 Oct 2009 Posts: 116
|
Posted: Sun Jun 17, 2012 5:10 am Post subject: evdev thinks my headset is a mouse, goes crazy. |
|
|
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:
Code: | [ 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 |
|
Back to top |
|
|
audiodef Watchman
Joined: 06 Jul 2005 Posts: 6639 Location: The soundosphere
|
|
Back to top |
|
|
VoidMage Watchman
Joined: 14 Oct 2006 Posts: 6196
|
Posted: Sun Jun 17, 2012 6:23 pm Post subject: |
|
|
First, lets make sure it's really udev, that's misbehaving.
What does 'udevadm info' print about that headset ? |
|
Back to top |
|
|
Fitzcarraldo Advocate
Joined: 30 Aug 2008 Posts: 2034 Location: United Kingdom
|
Posted: Mon Jun 18, 2012 5:26 pm Post subject: |
|
|
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:
Code: | [ 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
Code: | 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:
Code: | usbhid.quirks=0x15a4:0x1001:0x0004 |
Then when I rebooted I saw the following for the DVB-T stick in the dmesg output:
Code: | [ 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. _________________ Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|