> > > The main thing to note is that in 3.18, when the driver fielded the mute > key events itself, it handled those events by toggling the state of a > low-level hardware-based mute switch (upper right dotted box). This HW mute > evidently applied only to the speaker, not headphones, and seems to have no > relationship to the pavucontrol/pactl/amixer mixer-based mute. Also -- and > central to the issue here -- invoking the HW mute function via the mute key > also toggled the mute LED, and that LED state always faithfully reflected > the actual mute state (LED on == speaker audio off, always). In the other > direction, there was never any observed effect on the mute LED state as a > result of toggling the mixer-based Master Playback mute, via pavuconrol, > pactl, pacmd, or amixer (or in any other way that I ever found). In short, > the mute LED in 3.18 seems like it's solely under control of the mute key > event as fielded by the driver. > > In 3.19, the mute key is no longer fielded directly by the driver; it becomes > simply an ordinary userspace key. That was an intentional change and certainly > not a bug. But the point is that in 3.19, if the user wishes to perform muting > in userspace (e.g., by "pactl"ing the mixer mute function in response to a > mute key event, or by clicking the pavucontrol mute icon, or by issuing an > amixer or pactl command) it's not going to have the same effect that the > driver used to realize in 3.18, in two ways: One is relatively minor, and > the other is central to the issue here: > > * First, and obviously, it isn't going institute the mute function via the > HW mute, but rather via the mixer-based Master Playback mute. This in > itself is probably no big deal: There are some minor functional differences > between the HW mute and the mixer mute, but most users won't care and > it's probably not a very important issue. Let's ignore it here. > > * Second -- and here is the real issue -- since the mixer-based Master > Playback mute has (and never had, even in 3.18) any effect on the mute > LED (on my T-510) the mute LED does not follow the mixer-based mute > state. It's always off. There just doesn't seem to be any way turn on > the mute LED via pavucontrol, pactl, pacmd, or amixer. > > The second item is the real head-scratcher: Not only is the functionality of > the mute LED lost in 3.19 (on my T-510 at least) but it is David's expectation > that the LED _ought_ to be following the Master Playback mixer mute state, > yet it does not. Apr 16 15:56:17 ga kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.25 Apr 16 15:56:17 ga kernel: thinkpad_acpi:<a href="http://ibm-acpi.sf.net/"> http://ibm-acpi.sf.net/</a> Apr 16 15:56:17 ga kernel: thinkpad_acpi: ThinkPad BIOS 6MET81WW (1.41 ), EC 6MHT43WW-1.18 Apr 16 15:56:17 ga kernel: thinkpad_acpi: Lenovo ThinkPad T510, model 4314DPU Apr 16 15:56:17 ga kernel: thinkpad_acpi: detected a 16-level brightness capable ThinkPad Apr 16 15:56:17 ga kernel: thinkpad_acpi: radio switch found; radios are enabled Apr 16 15:56:17 ga kernel: thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver Apr 16 15:56:17 ga kernel: thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... Apr 16 15:56:17 ga kernel: thinkpad_acpi: Standard ACPI backlight interface available, not loading native one Apr 16 15:56:17 ga kernel: input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input7 <a href="https://bugzilla.kernel.org/show_bug.cgi?id=96171">https://bugzilla.kernel.org/show_bug.cgi?id=96171</a> Let user know whether the mute led or mic led interface is supported by tpacpi_led_set() when thinkpad_acpi is loaded static int mute_led_init(struct ibm_init_struct *iibm) { acpi_handle temp; int i; for (i = 0; i < TPACPI_LED_MAX; i++) { struct tp_led_table *t = &led_tables[i]; - if (ACPI_SUCCESS(acpi_get_handle(hkey_handle, t->name, &temp))) + if (ACPI_SUCCESS(acpi_get_handle(hkey_handle, t->name, &temp))) { + pr_info("Thinkpad led %s interface supported.\n", t->name); mute_led_on_off(t, false); + } else t->state = -ENODEV; } return 0; }