Subject : multi-media key "mute" no longer recognized Submitter : Toralf Förster <toralf.foerster@gmx.de> Date : 2012-01-23 10:52 Message-ID : 201201231152.25344.toralf.foerster@gmx.de References : http://marc.info/?l=linux-kernel&m=132731613606121&w=2 This entry is being used for tracking a regression from 3.1. Please don't close it until the problem is fixed in the mainline.
with xev I get only one small diff related to "serial": tfoerste@n22 ~ $ tail -v mute-3.* ==> mute-3.0.21 <== KeyRelease event, serial 33, synthetic NO, window 0x4600001, root 0xc3, subw 0x0, time 293494, (1260,275), root:(1262,298), state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ==> mute-3.2.6 <== KeyRelease event, serial 32, synthetic NO, window 0x3a00001, root 0xc3, subw 0x0, time 3424766, (-1217,745), root:(74,768), state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
The key (no pun intended) in getting this solved is cc'ing the right people.
Since they keypress is "visible" in X this is certainly not a kernel problem.
(In reply to comment #3) > Since they keypress is "visible" in X this is certainly not a kernel problem. Well, why does booting my Gentoo with any kernel of the 3.0x series doesn't show the problem while booting with 3.1.x or 3.2.x kernel shows it ? Where shoukld I reprot this problem then nstead ?
Do you know what component reacts to XF86AudioMute on Gentoo? I'd start with your desktop environment.
Can you bisect between 3.0 and 3.1 to find what change caused this to happen? [Did you change your userspace?] Also can you provide 'good' and 'bad' dmesg? Dmitry, please don't close this off, just because the cause is yet unknown. I agree, that it doesn't look like the xev snippet from above gives us any hint on where the problem is, but booting one kernel and getting a working system and booting another kernel and getting a broken system looks like it's the kernels fault.
I checked again today with kernels 3.0.22, 3.1.10 and 3.2.29-rc1 - the regression is between 3.1.x and 3.2.x, one thing between the dmesg (I'll attach all) is shown here : tfoerste@n22 ~/tmp $ grep -i -e snd -e sound -e hda dmesg-3.1.10 dmesg-3.2.9-rc1 dmesg-3.1.10:snd_hda_intel 0000:00:1b.0: PCI INT B -> GSI 17 (level, low) -> IRQ 17 dmesg-3.1.10:snd_hda_intel 0000:00:1b.0: irq 47 for MSI/MSI-X dmesg-3.1.10:snd_hda_intel 0000:00:1b.0: setting latency timer to 64 dmesg-3.1.10:input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 dmesg-3.1.10:input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7 dmesg-3.1.10:input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8 dmesg-3.1.10:input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9 dmesg-3.2.9-rc1:snd_hda_intel 0000:00:1b.0: PCI INT B -> GSI 17 (level, low) -> IRQ 17 dmesg-3.2.9-rc1:snd_hda_intel 0000:00:1b.0: irq 46 for MSI/MSI-X dmesg-3.2.9-rc1:snd_hda_intel 0000:00:1b.0: setting latency timer to 64 dmesg-3.2.9-rc1:hda_codec: CX20561 (Hermosa): BIOS auto-probing. dmesg-3.2.9-rc1:input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input6
Created attachment 72496 [details] dmesg 3.1.x
Created attachment 72497 [details] dmesg 3.2.x
solved by 3868137 at my system (cherry picked and applied on top of 3.2.9).