[NOTE: This is an edited/expanded version of a previous post which never made
it to the list because it had an attachment that was too big.]
David Henningsson <david.henningsson at canonical.com> [2015-04-14 13:32:42 +0200]:
>
> Just to check - you did press F4 or F5 to make all capture controls show up,
> right?
>
Yes. I also widened out the display to make sure there were no more controls
hidden on either side.
In case it may be of interest to anyone with the same or similar issue,
here is a "behavioral schematic" that seems to accurately reflect the
relationship between {pavucontrol/pactl/pacmd/amixer} mute and the hardware
mute function and LEDs on my T-510, showing the differences across the
kernel change between 3.18 and 3.19:
http://misc.postpro.net/t510led/schematic_view.jpg
(The diagram isn't intended to reflect actual circuit topology, of which
I have no knowledge; only that it seems to schematically capture the observed
muting (and mute LED) behavior.)
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.
Hope this helps to understand the issue better.
