On Mon, Feb 16, 2015 at 7:35 AM, Xavier Naveira <xnaveira@xxxxxxxxx> wrote: > On Mon, Feb 16, 2015 at 07:24:43AM -0800, Andrew Lutomirski wrote: >> On Feb 16, 2015 3:59 AM, "Xavier Naveira" <xnaveira@xxxxxxxxx> wrote: >> > >> > Hi, >> > >> > Since the kernel 3.19 mute button stopped working for me, this seems to >> > be the commit: >> > >> > >> http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/commitdiff/9a417ec0c9d1f7af5394333411fc4d98adb8761b >> > >> > Before that (3.18.7) the button worked as well as its led although the >> > state was reset to "unmuted" after suspend. >> > >> > I'm on a Lenovo thinkpad x240 running ubuntu 14.10 with kernel compiled >> > from kernel.org. >> > >> > I'll be glad to help debugging the problem. >> >> What desktop environment are you using? I suspect that you are >> misconfigured a bit, since I've had reports that this works on the X240. I >> really ought to write a blog post about it. >> >> --Andy >> >> > >> > >> > Xavier > > Hi Andy, > > My desktop environent is i3 on top of a default installation of xubuntu. > The kernel is the only thing that changes and I can reproduce the > problem every time. Here's the basics of what's going on: Prior to 3.19, the ThinkPad embedded controller would automatically mute a ThinkPad-specific hardware switch and light an LED when you pressed the mute button. The kernel had partial support for this: on more recent kernels, it would try to keep the LED in sync with the *standard* (non-ThinkPad-specific) mute controls, and it exposed a rather buggy separate ALSA mixer that could directly poke the ThinkPad hardware control. The upshot was that, depending on what your userspace software was doing, the mute button would sometimes do something vaguely like what you expected, and it would sometimes behave erratically. Starting with 3.19, the default behavior is to ask the embedded controller to disable all the magic. The kernel will keep the mute LED in sync with the software control, the hardware switch is disabled entirely, and the mute button is just a button. In other words, a ThinkPad on 3.19 or newer will work just like any other laptop, except with a bonus mute LED. If you were relying on the old behavior, your mute button might no longer have any apparent effect. Users of more full-featured desktop environments (GNOME and KDE, I think) seem to be fine by default. Otherwise, you might need to set up your desktop environment the same way you would for a non-ThinkPad laptop. To get you started, try these commands from a shell: To toggle the mute state: $ amixer -q set Master toggle To toggle the mic mute state: $ amixer -q set Capture toggle If these work, then you should be able to bind them to the appropriate key presses using a desktop-specific configuration along the lines of: bindsym XF86AudioMute exec amixer -q set Master toggle As an alternative, you can get the old behavior back by setting thinkpad_acpi.software_mute=0, but then you'll have the same problem again if you ever migrate to a non-ThinkPad laptop or if Lenovo ever decides to save a few cents on new models by getting rid of the extra hardware mute control. --Andy > > X ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel