Bug 198597

In case it helps... I have attached a copy of my Kernel configuration (4.14).

Created attachment 273897 [details]
Kernel Config - 4.14.12

Here's a dump of my DSDT table...

Created attachment 273899 [details]
DSDT Table

(In reply to Mingcong Bai from comment #0)
> On a Lenovo ThinkPad L420 (Type 7854)...
> 
> - Neither the LED nor the button for Microphone Mute works, the
> `acpi_listen` command does not return with any readings. Pressing the button
> won't mute the microphone, nor would it light up the LED. However, using a
> volume mixer application (say, the one I used was from MATE Desktop) and
> drag the microphone volume all the way down, or checking "mute" will light
> up the button.

when does this happen?

> - The mute button works, but the LED does not light up. The mute LED could
> be lit or unlit before booting Linux. Pressing the button registers the
> following with the `acpi_listen` command:
> 

when does this happen?

what did you do to reproduce the two different symptoms?
Or the laptop is broken all the time, but with two different symptoms?

(In reply to Zhang Rui from comment #5)
> (In reply to Mingcong Bai from comment #0)
> > On a Lenovo ThinkPad L420 (Type 7854)...
> > 
> > - Neither the LED nor the button for Microphone Mute works, the
> > `acpi_listen` command does not return with any readings. Pressing the
> button
> > won't mute the microphone, nor would it light up the LED. However, using a
> > volume mixer application (say, the one I used was from MATE Desktop) and
> > drag the microphone volume all the way down, or checking "mute" will light
> > up the button.
> 
> when does this happen?

It happens the moment after I booted Linux Kernel from GRUB (my bootloader of choice), and when I'm not done booting Windows (along with the Lenovo drivers supplied).

In short, it happens when I'm running Linux... or any other OS(es) without driver or system support.

> > - The mute button works, but the LED does not light up. The mute LED could
> > be lit or unlit before booting Linux. Pressing the button registers the
> > following with the `acpi_listen` command:
> > 
> 
> when does this happen?

Same scenario as above.

> what did you do to reproduce the two different symptoms?

Again, same scenario. It only works when...

1. The system is running in "Real Mode" (so to speak), under control of the BIOS.
2. When running Windows 7/8/8.1/10 - the only systems with these "hotkey" support drivers.

> Or the laptop is broken all the time, but with two different symptoms?

Given my responses above, I can certify that there's no hardware issue with my laptop.

(In reply to Mingcong Bai from comment #6)
> (In reply to Zhang Rui from comment #5)
> > (In reply to Mingcong Bai from comment #0)
> > > On a Lenovo ThinkPad L420 (Type 7854)...
> > > 
> > > - Neither the LED nor the button for Microphone Mute works, the
> > > `acpi_listen` command does not return with any readings. Pressing the
> > button
> > > won't mute the microphone, nor would it light up the LED. However, using
> a
> > > volume mixer application (say, the one I used was from MATE Desktop) and
> > > drag the microphone volume all the way down, or checking "mute" will
> light
> > > up the button.
> > 
> > when does this happen?
> 
> It happens the moment after I booted Linux Kernel from GRUB (my bootloader
> of choice), and when I'm not done booting Windows (along with the Lenovo
> drivers supplied).
> 
> In short, it happens when I'm running Linux... or any other OS(es) without
> driver or system support.
> 
> > > - The mute button works, but the LED does not light up. The mute LED
> could
> > > be lit or unlit before booting Linux. Pressing the button registers the
> > > following with the `acpi_listen` command:
> > > 
> > 
> > when does this happen?
> 
> Same scenario as above.
> 
No, the above two symptoms are exclusive.
there is no acpi_listen output in the first symptom, while there is, in the second one.
Thus I don't understand why you get different results in the same scenario.

> No, the above two symptoms are exclusive.
> there is no acpi_listen output in the first symptom, while there is, in the
> second one.
> Thus I don't understand why you get different results in the same scenario.

Sorry my mistake, let me rephrase this one more time, in a list:

1. The Microphone Mute button is not at all detected or recognised in Linux (it works when in BIOS or GRUB, or in Windows with appropriate drivers installed).
1.a. Though it isn't recognised, not even by `acpi_listen`, when I used MATE Desktop's audio setting to mute or turn the microphone volume all the way down, the LED lights up.
2. The Mute button works under Linux - mutes audio output just fine. However the LED on the button does not light up when the audio is muted. Again, the mute button works as expected (muting the audio, AND lighting up its LED when it's active) when in BIOS or GRUB, and in Windows with appropriate drivers installed.
2.a. Yes, `acpi_listen` does recognise a key-press event with this button, unlike the Microphone mute button.

To help clarify what I'm talking about, here's a close-up photograph of the buttons I'm talking about:

http://notebooks.wpengine.netdna-cdn.com/wp-content/uploads/2011/02/L420_detail_02.jpg

- The top button is the "Microphone Mute" button in question, it has a red LED which lights up when the microphone is muted.
- The bottom button is the "Mute" button, also has a red LED which lights up when the audio output is muted.

The rest is discussed above.

It also seems like that custom button events are defined in the Kernel by the thinkpad-acpi module, reading the source I did find some "safe LED" definitions, which involves other models of the same era (T420, etc.), but not this computer, could this be related?

I see.
so there are two problems with two different mute buttons, one for microphone and another one for speaker.
Anyway, this sounds like a platform specific issue to me. Bug reassigned.

(In reply to Zhang Rui from comment #11)
> I see.
> so there are two problems with two different mute buttons, one for
> microphone and another one for speaker.
> Anyway, this sounds like a platform specific issue to me. Bug reassigned.

Thanks for the check in.