Description of problem: Mute button on USB microphone works like left mouse button Version-Release number of selected component (if applicable): 3.10.10 How reproducible: always Steps to Reproduce: 1. plug in microphone 2. press mute button 3. Actual results: Works like left mouse button Expected results: should mute the microphone Additional info: [ 1.737762] usb 4-1: new full-speed USB device number 2 using ohci_hcd [ 1.928847] usb 4-1: New USB device found, idVendor=17a0, idProduct=0310 [ 1.928861] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1.928870] usb 4-1: Product: Samson Meteor Mic [ 1.928877] usb 4-1: Manufacturer: Samson Technologies [ 1.942272] input: Samson Technologies Samson Meteor Mic as /devices/pci0000:00/0000:00:06.0/usb4/4-1/4-1:1.3/input/input5 [ 1.942902] hid-generic 0003:17A0:0310.0001: input,hiddev0,hidraw0: USB HID v1.00 Device [Samson Technologies Samson Meteor Mic] on usb-0000:00:06.0-1/input3
Hi Robert, did this work before the 3.10.x kernels or is it a new device you started using? cheers, Michele
(In reply to Michele Baldessari from comment #1) Hi Michele > did this work before the 3.10.x kernels or is it a new device you started > using? this is a new device I used for the first time. I just tested with a 3.9.5 kernel and see the same effect there. Robert
Hi Robert, thanks for the confirmation. Can you do the following? Make sure that the webcam driver is loaded and that the webcam is active (otherwise no input is generated), so maybe open cheese or a program that uses the webcam. After that in another terminal launch 'evtest' (in the package evtest). You will get something like the following: $ sudo evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: Lid Switch /dev/input/event1: Power Button /dev/input/event10: HDA Intel PCH HDMI/DP,pcm=8 /dev/input/event11: HDA Intel PCH HDMI/DP,pcm=7 /dev/input/event12: HDA Intel PCH HDMI/DP,pcm=3 /dev/input/event13: HDA Intel PCH Headphone /dev/input/event2: Sleep Button /dev/input/event3: Power Button /dev/input/event4: Apple Inc. Apple Internal Keyboard / Trackpad /dev/input/event5: FaceTime Camera (Built-in) /dev/input/event6: UVC Camera (046d:0809) /dev/input/event7: Video Bus /dev/input/event8: Logitech USB Laser Mouse /dev/input/event9: bcm5974 Here choose your model: Select the device event number [0-13]: 6 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0x46d product 0x809 version 0x10 Input device name: "UVC Camera (046d:0809)" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 212 (KEY_CAMERA) Properties: Testing ... (interrupt to exit) And then press the button a few times: Event: time 1378667256.870113, type 1 (EV_KEY), code 212 (KEY_CAMERA), value 1 Event: time 1378667256.870113, -------------- SYN_REPORT ------------ Event: time 1378667265.605917, type 1 (EV_KEY), code 212 (KEY_CAMERA), value 0 Event: time 1378667265.605917, -------------- SYN_REPORT ------------ Event: time 1378667276.693532, type 1 (EV_KEY), code 212 (KEY_CAMERA), value 1 Event: time 1378667276.693532, -------------- SYN_REPORT ------------ Event: time 1378667276.965573, type 1 (EV_KEY), code 212 (KEY_CAMERA), value 0 Event: time 1378667276.965573, -------------- SYN_REPORT ------------ Event: time 1378667889.535174, type 1 (EV_KEY), code 212 (KEY_CAMERA), value 1 Event: time 1378667889.535174, -------------- SYN_REPORT ------------ Event: time 1378667889.711191, type 1 (EV_KEY), code 212 (KEY_CAMERA), value 0 Event: time 1378667889.711191, -------------- SYN_REPORT ------------ Event: time 1378667890.239159, type 1 (EV_KEY), code 212 (KEY_CAMERA), value 1 Event: time 1378667890.239159, -------------- SYN_REPORT ------------ Event: time 1378667890.431136, type 1 (EV_KEY), code 212 (KEY_CAMERA), value 0 Event: time 1378667890.431136, -------------- SYN_REPORT ------------ Please get me the full output of the evtest command after choosing the camera and pressing the mute button a few times. Also get me the output of lsusb -v -d 17A0:0310 thanks, Michele
Created attachment 795394 [details] output of evtest
Created attachment 795395 [details] output of lsusb
Hi Michele, I hope I have created the correct output. Just to be sure, the device is not a webcam, but a microphone. See http://www.samsontech.com/samson/products/microphones/usb-microphones/meteormic/ for more information. From the evtest output I am a bit surprised about all the event codes listed under event type 1. 113 (Mute) is OK. While there is a volume control, it should only act on the headphone output jack on the back of the microphone and not be passed on to the computer (and turning the volume control while evtest was running did not produce any output). There are no buttons for the 160 event codes. Thanks Robert
Hi Robert, yes I meant microfone, sorry ;) It might very well be that the supported events is just what is advertised via usb and not what ends up sent to the PC in the end. So if I understood correctly when you press the mute button it is sending the BTN_0 code instead instead of something like KEY_MUTE: Event: time 1378669437.606955, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1ff0001 Event: time 1378669437.606955, type 1 (EV_KEY), code 256 (BTN_0), value 1 Event: time 1378669437.606955, type 1 (EV_KEY), code 256 (BTN_0), value 0 Event: time 1378669437.606955, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 0 Is my understanding correct here? I assume (I genuinely have zero clue about the input subsystem) we have two options here: 1) See if the kernel driver allows for quirks so that we map the correct key in the driver itself 2) We remap the key for this specific button somehow in userspace For 2) I think the steps should be something like this (totally untested): We need to edit /usr/lib/udev/hwdb.d/60-keyboard.hwdb and add something like (adding 0100 which is the hex for 256 aka BTN_0): keyboard:usb:v17A0p0310*: KEYBOARD_KEY_0100=micmute NOTE: The vendor and product id must be in hex and UPPERCASE, wherease the KEYBOARD_KEYBOARD_wxyz (wxyz need to be lower case) Then we need to update the db which is under /etc/udev/hwdb.bin via: udevadm hwdb --update To verify that it picked up the change: # udevadm test /class/input/event12 2>&1 |grep KEYBOARD KEYBOARD_KEY_0100=micmenu Then cross fingers and see if after a reboot it all magically works ;) Could you also upload udevadm info --query=all --path=/sys/class/input/event12 ? Thanks, Michele
Created attachment 795421 [details] output of udevadm
(In reply to Michele Baldessari from comment #7) Hi Michele, > So if I understood correctly when you press the mute button it is sending > the BTN_0 code instead instead of something like KEY_MUTE: > > Event: time 1378669437.606955, type 4 (EV_MSC), code 4 (MSC_SCAN), value > 1ff0001 > Event: time 1378669437.606955, type 1 (EV_KEY), code 256 (BTN_0), value 1 > Event: time 1378669437.606955, type 1 (EV_KEY), code 256 (BTN_0), value 0 > Event: time 1378669437.606955, type 3 (EV_ABS), code 48 > (ABS_MT_TOUCH_MAJOR), value 0 > > Is my understanding correct here? Well, you definitely know better than me - but I certainly agree that it looks like that. The value=1 then means button pressed, and value=0 button released. > 2) We remap the key for this specific button somehow in userspace Tried this suggestion. > To verify that it picked up the change: > # udevadm test /class/input/event12 2>&1 |grep KEYBOARD > KEYBOARD_KEY_0100=micmenu The verification unfortunately produces no output. I ran the database update with --debug and the 60-keyboard.hwdb file is being read. Thanks Robert
Hi Robert, can you get me the /usr/lib/udev/hwdb.d/60-keyboard.hwdb file? thanks, Michele
Created attachment 796122 [details] created 60-keyboard.hwdb file
Hi Robert, you have: keyboard:usb:v17A0p0310*: KEYBOARD_KEY_0100=micmute Can you remove the last ':' and put: keyboard:usb:v17A0p0310* KEYBOARD_KEY_0100=micmute Reboot the box and then verify that: # udevadm test /class/input/event12 2>&1 |grep KEYBOARD KEYBOARD_KEY_0100=micmenu thanks, Michele
Hi Michele, unfortunately this does not seem to work - with or without the final ":" Thanks Robert
Hi Robert, crap! I was looking at a F20 system when I outlined my steps. I'll need to see how this will have to work for F19 I'll get back to you on this cheers, Michele
Hi Michele, thanks for your efforts. As this does not seem to be a kernel problem but rather a "problem" of the device that eventually can be worked around in user space, I certainly can wait for F20 for a solution. Thanks Robert
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Hi Robert, let me know if/when you get around trying the suggestions on F20 and we'll take it from there. Kind regards, Michele
Hi Michele, have updated to F20 now and added keyboard:usb:v17A0p0310* KEYBOARD_KEY_0100=micmute to /usr/lib/udev/hwdb.d/60-keyboard.hwdb as suggested. The output of # udevadm test /class/input/event12 2>&1 |grep KEYBOARD KEYBOARD_KEY_0100=micmute looks OK. It also appears in the output of the "udevadm info" command. The result is unfortunately the same though - the mute button still works like the left mouse button. Regards Robert
Created attachment 842798 [details] output of udevadm test for F20
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.