Re: Exposing the ThinkPad HW mute switch to ALSA?

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Takashi Iwai]

At Tue, 23 Sep 2014 19:16:52 -0700,
Andy Lutomirski wrote:
> 
> ThinkPads have an extra mute switch that's controlled by the embedded
> controller.  There are some hardware buttons associated with it.
> 
> We (thinkpad-acpi) can be notified about state changes in the mute
> switch, we can see presses of the hardware buttons and program them to
> send KEY_MUTE or not as appropriate, and we can (optionally) change
> the HW mute state.
> 
> However, I have no clue how to correctly expose the mute switch
> through ALSA so that userspace will know what it controls.  It
> currently shows up as its own sound card, which is ridiculous.
> 
> Can anyone give me any hints as to how to expose this bonus audio
> control in a sensible manner?  I know essentially nothing about ALSA.
> 
> (Some older ThinkPads also have a hardware volume control with similar
> behavior.)

It's a bit difficult issue, since this needs the weak module
dependency.  And even worse, different sound drivers might be used for
a single thinkpad_acpi.  So, from the programming POV, the individual
sound card instance is the easiest approach.

Though, some HD-audio codec drivers already have a weak binding of
thinkpad_acpi stuff for Mic-mute switch.  I guess we can move the
handling of the master mute switch to the sound driver as well.

If doing so, each relevant sound driver needs to implement it.
IIRC, snd-intel8x0 is used on old Thinkpads.  Any others?


Takashi

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Henrique de Moraes Holschuh]

On Mon, 06 Oct 2014, Takashi Iwai wrote:
> > ThinkPads have an extra mute switch that's controlled by the embedded
> > controller.  There are some hardware buttons associated with it.
> > 
> > We (thinkpad-acpi) can be notified about state changes in the mute
> > switch, we can see presses of the hardware buttons and program them to
> > send KEY_MUTE or not as appropriate, and we can (optionally) change
> > the HW mute state.
> > 
> > However, I have no clue how to correctly expose the mute switch
> > through ALSA so that userspace will know what it controls.  It
> > currently shows up as its own sound card, which is ridiculous.
> > 
> > Can anyone give me any hints as to how to expose this bonus audio
> > control in a sensible manner?  I know essentially nothing about ALSA.
> > 
> > (Some older ThinkPads also have a hardware volume control with similar
> > behavior.)
> 
> It's a bit difficult issue, since this needs the weak module
> dependency.  And even worse, different sound drivers might be used for
> a single thinkpad_acpi.  So, from the programming POV, the individual
> sound card instance is the easiest approach.
> 
> Though, some HD-audio codec drivers already have a weak binding of
> thinkpad_acpi stuff for Mic-mute switch.  I guess we can move the
> handling of the master mute switch to the sound driver as well.
> 
> If doing so, each relevant sound driver needs to implement it.
> IIRC, snd-intel8x0 is used on old Thinkpads.  Any others?

As far as I know, all old ones use the snd-intel8x0 AC97 hba, but several
different codecs behind that.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Andy Lutomirski]

On Mon, Oct 6, 2014 at 12:09 PM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Mon, 06 Oct 2014, Takashi Iwai wrote:
>> > ThinkPads have an extra mute switch that's controlled by the embedded
>> > controller.  There are some hardware buttons associated with it.
>> >
>> > We (thinkpad-acpi) can be notified about state changes in the mute
>> > switch, we can see presses of the hardware buttons and program them to
>> > send KEY_MUTE or not as appropriate, and we can (optionally) change
>> > the HW mute state.
>> >
>> > However, I have no clue how to correctly expose the mute switch
>> > through ALSA so that userspace will know what it controls.  It
>> > currently shows up as its own sound card, which is ridiculous.
>> >
>> > Can anyone give me any hints as to how to expose this bonus audio
>> > control in a sensible manner?  I know essentially nothing about ALSA.
>> >
>> > (Some older ThinkPads also have a hardware volume control with similar
>> > behavior.)
>>
>> It's a bit difficult issue, since this needs the weak module
>> dependency.  And even worse, different sound drivers might be used for
>> a single thinkpad_acpi.  So, from the programming POV, the individual
>> sound card instance is the easiest approach.
>>
>> Though, some HD-audio codec drivers already have a weak binding of
>> thinkpad_acpi stuff for Mic-mute switch.  I guess we can move the
>> handling of the master mute switch to the sound driver as well.
>>
>> If doing so, each relevant sound driver needs to implement it.
>> IIRC, snd-intel8x0 is used on old Thinkpads.  Any others?
>
> As far as I know, all old ones use the snd-intel8x0 AC97 hba, but several
> different codecs behind that.

FWIW, I don't know whether any of the pre-hda thinkpads have the ACPI
HAUM/SAUM mechanism, so I have no idea how good our support for the
hardware mute switch and controls will ever be on those laptops.

--Andy

>
> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Takashi Iwai]

At Mon, 6 Oct 2014 17:06:19 -0700,
Andy Lutomirski wrote:
> 
> On Mon, Oct 6, 2014 at 12:09 PM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > On Mon, 06 Oct 2014, Takashi Iwai wrote:
> >> > ThinkPads have an extra mute switch that's controlled by the embedded
> >> > controller.  There are some hardware buttons associated with it.
> >> >
> >> > We (thinkpad-acpi) can be notified about state changes in the mute
> >> > switch, we can see presses of the hardware buttons and program them to
> >> > send KEY_MUTE or not as appropriate, and we can (optionally) change
> >> > the HW mute state.
> >> >
> >> > However, I have no clue how to correctly expose the mute switch
> >> > through ALSA so that userspace will know what it controls.  It
> >> > currently shows up as its own sound card, which is ridiculous.
> >> >
> >> > Can anyone give me any hints as to how to expose this bonus audio
> >> > control in a sensible manner?  I know essentially nothing about ALSA.
> >> >
> >> > (Some older ThinkPads also have a hardware volume control with similar
> >> > behavior.)
> >>
> >> It's a bit difficult issue, since this needs the weak module
> >> dependency.  And even worse, different sound drivers might be used for
> >> a single thinkpad_acpi.  So, from the programming POV, the individual
> >> sound card instance is the easiest approach.
> >>
> >> Though, some HD-audio codec drivers already have a weak binding of
> >> thinkpad_acpi stuff for Mic-mute switch.  I guess we can move the
> >> handling of the master mute switch to the sound driver as well.
> >>
> >> If doing so, each relevant sound driver needs to implement it.
> >> IIRC, snd-intel8x0 is used on old Thinkpads.  Any others?
> >
> > As far as I know, all old ones use the snd-intel8x0 AC97 hba, but several
> > different codecs behind that.
> 
> FWIW, I don't know whether any of the pre-hda thinkpads have the ACPI
> HAUM/SAUM mechanism, so I have no idea how good our support for the
> hardware mute switch and controls will ever be on those laptops.

IIRC, they have, and the mute worked completely independently from the
onboard sound controller.  But my memory is pretty vague.


Takashi

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Grant Diffey]

so I have a really dumb question.

Why can't the controls be mapped as HCI rather than a soundcard? given
there's no audio production capability here only a control capability.

Also this seems to be how they end up functioning on a modern system they
get bound to pulse which remaps them to whatever's 'active'

Why does everyone say that this is a soundcard when it's really a keyboard
(from my pov)

also what's the least surprise here?

Should this control control volume of my BT headset when it's active (It
currently does which I find convenient but I can see an argument that it's
surprising and should be bound to the phys hardware on the laptop)

On Tue, Oct 7, 2014 at 4:25 PM, Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 6 Oct 2014 17:06:19 -0700,
> Andy Lutomirski wrote:
> >
> > On Mon, Oct 6, 2014 at 12:09 PM, Henrique de Moraes Holschuh
> > <hmh@hmh.eng.br> wrote:
> > > On Mon, 06 Oct 2014, Takashi Iwai wrote:
> > >> > ThinkPads have an extra mute switch that's controlled by the
> embedded
> > >> > controller.  There are some hardware buttons associated with it.
> > >> >
> > >> > We (thinkpad-acpi) can be notified about state changes in the mute
> > >> > switch, we can see presses of the hardware buttons and program them
> to
> > >> > send KEY_MUTE or not as appropriate, and we can (optionally) change
> > >> > the HW mute state.
> > >> >
> > >> > However, I have no clue how to correctly expose the mute switch
> > >> > through ALSA so that userspace will know what it controls.  It
> > >> > currently shows up as its own sound card, which is ridiculous.
> > >> >
> > >> > Can anyone give me any hints as to how to expose this bonus audio
> > >> > control in a sensible manner?  I know essentially nothing about
> ALSA.
> > >> >
> > >> > (Some older ThinkPads also have a hardware volume control with
> similar
> > >> > behavior.)
> > >>
> > >> It's a bit difficult issue, since this needs the weak module
> > >> dependency.  And even worse, different sound drivers might be used for
> > >> a single thinkpad_acpi.  So, from the programming POV, the individual
> > >> sound card instance is the easiest approach.
> > >>
> > >> Though, some HD-audio codec drivers already have a weak binding of
> > >> thinkpad_acpi stuff for Mic-mute switch.  I guess we can move the
> > >> handling of the master mute switch to the sound driver as well.
> > >>
> > >> If doing so, each relevant sound driver needs to implement it.
> > >> IIRC, snd-intel8x0 is used on old Thinkpads.  Any others?
> > >
> > > As far as I know, all old ones use the snd-intel8x0 AC97 hba, but
> several
> > > different codecs behind that.
> >
> > FWIW, I don't know whether any of the pre-hda thinkpads have the ACPI
> > HAUM/SAUM mechanism, so I have no idea how good our support for the
> > hardware mute switch and controls will ever be on those laptops.
>
> IIRC, they have, and the mute worked completely independently from the
> onboard sound controller.  But my memory is pretty vague.
>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Takashi Iwai]

At Tue, 7 Oct 2014 17:25:13 +1100,
Grant Diffey wrote:
> 
> so I have a really dumb question.
> 
> Why can't the controls be mapped as HCI rather than a soundcard? given
> there's no audio production capability here only a control capability.
> 
> Also this seems to be how they end up functioning on a modern system they
> get bound to pulse which remaps them to whatever's 'active'
> 
> Why does everyone say that this is a soundcard when it's really a keyboard
> (from my pov)

thinkpad_acpi actually mutes the sound on some models, at least the
old ones, independently from the sound chip mute state.  That's why it
was implemented as the sound card object initially.


Takashi

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Henrique de Moraes Holschuh]

On Tue, 07 Oct 2014, Grant Diffey wrote:
> so I have a really dumb question.
> 
> Why can't the controls be mapped as HCI rather than a soundcard? given
> there's no audio production capability here only a control capability.
> 
> Also this seems to be how they end up functioning on a modern system they
> get bound to pulse which remaps them to whatever's 'active'

FYI, on the old thinkpads it is the console audio volume control.  It *only*
affects the built-in speakers and the built-in headphone output.  It does
_not_ affect line-out.  It does _not_ affect add-in soundcards.  And it
operates entirely inside the EC, with zero need of any OS assistance.

Those thinkpads don't have a separate MIC-mute button, though.  I never
tested them for mic-mute functionality come to think of it... the AC97 mixer
in the soundcard can mute the mic, and I don't think there's an external MIC
mute, because the chip they used for digital console volume control doesn't
have mic channels.

> Should this control control volume of my BT headset when it's active (It
> currently does which I find convenient but I can see an argument that it's
> surprising and should be bound to the phys hardware on the laptop)

Both alternatives are acceptable, as long as it doesn't lie.  And on old
thinkpads, you must take special action and not feed it back into the
internal AC97 mixer, because it will _always_ control the console digital
volume, it cannot be overriden in the older models, and the override doesn't
work well because whomever wrote the EC code for the other operating modes
did not test it properly.

BTW: old thinkpads don't use an ACPI interface to interact with the EC
mixer, it is done by direct EC register access, and we whitelist the models
where it works (the list is complete AFAIK).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Henrique de Moraes Holschuh]

On Tue, 07 Oct 2014, Takashi Iwai wrote:
> At Tue, 7 Oct 2014 17:25:13 +1100,
> Grant Diffey wrote:
> > so I have a really dumb question.
> > 
> > Why can't the controls be mapped as HCI rather than a soundcard? given
> > there's no audio production capability here only a control capability.
> > 
> > Also this seems to be how they end up functioning on a modern system they
> > get bound to pulse which remaps them to whatever's 'active'
> > 
> > Why does everyone say that this is a soundcard when it's really a keyboard
> > (from my pov)
> 
> thinkpad_acpi actually mutes the sound on some models, at least the
> old ones, independently from the sound chip mute state.  That's why it
> was implemented as the sound card object initially.

That's how the hardware works, really.  One AC97 audio channel is routed to
a digital volume chip, and from there to the console headphone jack, and to
the built-in speakers.  line-out is not routed through this chip, and AFAIK
MIC/line-in is not routed through either this chip _or_ a separate mute
gate, either.

The EC controls this digital volume chip directly, it is independent from
the AC97 mixer.  The default behaviour cannot be changed in earlier
thinkpads, and trying to change it in later thinkpads (they're supposed to
have a legacy mode that is the same as the older models) doesn't work very
well.

Line-out and MIC are controlled only by the AC97 mixer in the older models
with digital volume control.

In newer-but-not-newest thinkpads, there are two mute gates, one for MIC,
and another for the speakers/headphones.  The EC controls those.  All volume
control is in the HDA mixer.

In the newest thinkpads, I think there's only a MIC mute gate controlled by
the EC, and everything else is in the HDA mixer.

And depeding on the EC operating mode and thinkpad model, the volume hotkeys
might interact with the mute state (unmuting on first press when it is
mute).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Andy Lutomirski]

On Oct 7, 2014 6:20 AM, "Henrique de Moraes Holschuh" <hmh@hmh.eng.br> wrote:
>
> On Tue, 07 Oct 2014, Takashi Iwai wrote:
> > At Tue, 7 Oct 2014 17:25:13 +1100,
> > Grant Diffey wrote:
> > > so I have a really dumb question.
> > >
> > > Why can't the controls be mapped as HCI rather than a soundcard? given
> > > there's no audio production capability here only a control capability.
> > >
> > > Also this seems to be how they end up functioning on a modern system they
> > > get bound to pulse which remaps them to whatever's 'active'
> > >
> > > Why does everyone say that this is a soundcard when it's really a keyboard
> > > (from my pov)
> >
> > thinkpad_acpi actually mutes the sound on some models, at least the
> > old ones, independently from the sound chip mute state.  That's why it
> > was implemented as the sound card object initially.
>
> That's how the hardware works, really.  One AC97 audio channel is routed to
> a digital volume chip, and from there to the console headphone jack, and to
> the built-in speakers.  line-out is not routed through this chip, and AFAIK
> MIC/line-in is not routed through either this chip _or_ a separate mute
> gate, either.
>
> The EC controls this digital volume chip directly, it is independent from
> the AC97 mixer.  The default behaviour cannot be changed in earlier
> thinkpads, and trying to change it in later thinkpads (they're supposed to
> have a legacy mode that is the same as the older models) doesn't work very
> well.
>
> Line-out and MIC are controlled only by the AC97 mixer in the older models
> with digital volume control.
>
> In newer-but-not-newest thinkpads, there are two mute gates, one for MIC,
> and another for the speakers/headphones.  The EC controls those.  All volume
> control is in the HDA mixer.
>
> In the newest thinkpads, I think there's only a MIC mute gate controlled by
> the EC, and everything else is in the HDA mixer.
>
> And depeding on the EC operating mode and thinkpad model, the volume hotkeys
> might interact with the mute state (unmuting on first press when it is
> mute).
>

On newish thinkpads (at least X60-X220, and I think this works on the
latest models as well), we can disable all of this and make the mute
button be a regular button if we want.  Getting the mute LED to DTRT
might be tricky, but modern userspace can probably do it.

This is almost certainly the approach that does something sensible
with the least code written.  We would just check for HAUM/SAUM on
startup and, if available, set SAUM to "software control only",
force-unmute the mute circuit, force the volume to full, and disable
the fake soundcard.

--Andy

> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Takashi Iwai]

At Tue, 7 Oct 2014 07:44:35 -0700,
Andy Lutomirski wrote:
> 
> On Oct 7, 2014 6:20 AM, "Henrique de Moraes Holschuh" <hmh@hmh.eng.br> wrote:
> >
> > On Tue, 07 Oct 2014, Takashi Iwai wrote:
> > > At Tue, 7 Oct 2014 17:25:13 +1100,
> > > Grant Diffey wrote:
> > > > so I have a really dumb question.
> > > >
> > > > Why can't the controls be mapped as HCI rather than a soundcard? given
> > > > there's no audio production capability here only a control capability.
> > > >
> > > > Also this seems to be how they end up functioning on a modern system they
> > > > get bound to pulse which remaps them to whatever's 'active'
> > > >
> > > > Why does everyone say that this is a soundcard when it's really a keyboard
> > > > (from my pov)
> > >
> > > thinkpad_acpi actually mutes the sound on some models, at least the
> > > old ones, independently from the sound chip mute state.  That's why it
> > > was implemented as the sound card object initially.
> >
> > That's how the hardware works, really.  One AC97 audio channel is routed to
> > a digital volume chip, and from there to the console headphone jack, and to
> > the built-in speakers.  line-out is not routed through this chip, and AFAIK
> > MIC/line-in is not routed through either this chip _or_ a separate mute
> > gate, either.
> >
> > The EC controls this digital volume chip directly, it is independent from
> > the AC97 mixer.  The default behaviour cannot be changed in earlier
> > thinkpads, and trying to change it in later thinkpads (they're supposed to
> > have a legacy mode that is the same as the older models) doesn't work very
> > well.
> >
> > Line-out and MIC are controlled only by the AC97 mixer in the older models
> > with digital volume control.
> >
> > In newer-but-not-newest thinkpads, there are two mute gates, one for MIC,
> > and another for the speakers/headphones.  The EC controls those.  All volume
> > control is in the HDA mixer.
> >
> > In the newest thinkpads, I think there's only a MIC mute gate controlled by
> > the EC, and everything else is in the HDA mixer.
> >
> > And depeding on the EC operating mode and thinkpad model, the volume hotkeys
> > might interact with the mute state (unmuting on first press when it is
> > mute).
> >
> 
> On newish thinkpads (at least X60-X220, and I think this works on the
> latest models as well), we can disable all of this and make the mute
> button be a regular button if we want.  Getting the mute LED to DTRT
> might be tricky, but modern userspace can probably do it.
> 
> This is almost certainly the approach that does something sensible
> with the least code written.  We would just check for HAUM/SAUM on
> startup and, if available, set SAUM to "software control only",
> force-unmute the mute circuit, force the volume to full, and disable
> the fake soundcard.

That sounds sensible.  But, we'll still need to handle the mute LED,
like we do for the mic-mute LED now?


Takashi

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Andy Lutomirski]

On Tue, Oct 7, 2014 at 7:50 AM, Takashi Iwai <tiwai@suse.de> wrote:
> At Tue, 7 Oct 2014 07:44:35 -0700,
> Andy Lutomirski wrote:
>>
>> On Oct 7, 2014 6:20 AM, "Henrique de Moraes Holschuh" <hmh@hmh.eng.br> wrote:
>> >
>> > On Tue, 07 Oct 2014, Takashi Iwai wrote:
>> > > At Tue, 7 Oct 2014 17:25:13 +1100,
>> > > Grant Diffey wrote:
>> > > > so I have a really dumb question.
>> > > >
>> > > > Why can't the controls be mapped as HCI rather than a soundcard? given
>> > > > there's no audio production capability here only a control capability.
>> > > >
>> > > > Also this seems to be how they end up functioning on a modern system they
>> > > > get bound to pulse which remaps them to whatever's 'active'
>> > > >
>> > > > Why does everyone say that this is a soundcard when it's really a keyboard
>> > > > (from my pov)
>> > >
>> > > thinkpad_acpi actually mutes the sound on some models, at least the
>> > > old ones, independently from the sound chip mute state.  That's why it
>> > > was implemented as the sound card object initially.
>> >
>> > That's how the hardware works, really.  One AC97 audio channel is routed to
>> > a digital volume chip, and from there to the console headphone jack, and to
>> > the built-in speakers.  line-out is not routed through this chip, and AFAIK
>> > MIC/line-in is not routed through either this chip _or_ a separate mute
>> > gate, either.
>> >
>> > The EC controls this digital volume chip directly, it is independent from
>> > the AC97 mixer.  The default behaviour cannot be changed in earlier
>> > thinkpads, and trying to change it in later thinkpads (they're supposed to
>> > have a legacy mode that is the same as the older models) doesn't work very
>> > well.
>> >
>> > Line-out and MIC are controlled only by the AC97 mixer in the older models
>> > with digital volume control.
>> >
>> > In newer-but-not-newest thinkpads, there are two mute gates, one for MIC,
>> > and another for the speakers/headphones.  The EC controls those.  All volume
>> > control is in the HDA mixer.
>> >
>> > In the newest thinkpads, I think there's only a MIC mute gate controlled by
>> > the EC, and everything else is in the HDA mixer.
>> >
>> > And depeding on the EC operating mode and thinkpad model, the volume hotkeys
>> > might interact with the mute state (unmuting on first press when it is
>> > mute).
>> >
>>
>> On newish thinkpads (at least X60-X220, and I think this works on the
>> latest models as well), we can disable all of this and make the mute
>> button be a regular button if we want.  Getting the mute LED to DTRT
>> might be tricky, but modern userspace can probably do it.
>>
>> This is almost certainly the approach that does something sensible
>> with the least code written.  We would just check for HAUM/SAUM on
>> startup and, if available, set SAUM to "software control only",
>> force-unmute the mute circuit, force the volume to full, and disable
>> the fake soundcard.
>
> That sounds sensible.  But, we'll still need to handle the mute LED,
> like we do for the mic-mute LED now?

Already done, I think:

        if (led_set_func(TPACPI_LED_MUTE, false) >= 0) {
            old_vmaster_hook = spec->vmaster_mute.hook;
            spec->vmaster_mute.hook = update_tpacpi_mute_led;
            removefunc = false;
        }

Admittedly, I see some value in having the mute button mute things
regardless of what userspace is doing, but I don't see *much* value in
it.  And, arguably, if that behavior is actually desirable, it should
be available on all laptops, not just ThinkPads.

--Andy

Re: Exposing the ThinkPad HW mute switch to ALSA?

[Takashi Iwai]

At Tue, 7 Oct 2014 17:43:11 -0700,
Andy Lutomirski wrote:
> 
> On Tue, Oct 7, 2014 at 7:50 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > At Tue, 7 Oct 2014 07:44:35 -0700,
> > Andy Lutomirski wrote:
> >>
> >> On Oct 7, 2014 6:20 AM, "Henrique de Moraes Holschuh" <hmh@hmh.eng.br> wrote:
> >> >
> >> > On Tue, 07 Oct 2014, Takashi Iwai wrote:
> >> > > At Tue, 7 Oct 2014 17:25:13 +1100,
> >> > > Grant Diffey wrote:
> >> > > > so I have a really dumb question.
> >> > > >
> >> > > > Why can't the controls be mapped as HCI rather than a soundcard? given
> >> > > > there's no audio production capability here only a control capability.
> >> > > >
> >> > > > Also this seems to be how they end up functioning on a modern system they
> >> > > > get bound to pulse which remaps them to whatever's 'active'
> >> > > >
> >> > > > Why does everyone say that this is a soundcard when it's really a keyboard
> >> > > > (from my pov)
> >> > >
> >> > > thinkpad_acpi actually mutes the sound on some models, at least the
> >> > > old ones, independently from the sound chip mute state.  That's why it
> >> > > was implemented as the sound card object initially.
> >> >
> >> > That's how the hardware works, really.  One AC97 audio channel is routed to
> >> > a digital volume chip, and from there to the console headphone jack, and to
> >> > the built-in speakers.  line-out is not routed through this chip, and AFAIK
> >> > MIC/line-in is not routed through either this chip _or_ a separate mute
> >> > gate, either.
> >> >
> >> > The EC controls this digital volume chip directly, it is independent from
> >> > the AC97 mixer.  The default behaviour cannot be changed in earlier
> >> > thinkpads, and trying to change it in later thinkpads (they're supposed to
> >> > have a legacy mode that is the same as the older models) doesn't work very
> >> > well.
> >> >
> >> > Line-out and MIC are controlled only by the AC97 mixer in the older models
> >> > with digital volume control.
> >> >
> >> > In newer-but-not-newest thinkpads, there are two mute gates, one for MIC,
> >> > and another for the speakers/headphones.  The EC controls those.  All volume
> >> > control is in the HDA mixer.
> >> >
> >> > In the newest thinkpads, I think there's only a MIC mute gate controlled by
> >> > the EC, and everything else is in the HDA mixer.
> >> >
> >> > And depeding on the EC operating mode and thinkpad model, the volume hotkeys
> >> > might interact with the mute state (unmuting on first press when it is
> >> > mute).
> >> >
> >>
> >> On newish thinkpads (at least X60-X220, and I think this works on the
> >> latest models as well), we can disable all of this and make the mute
> >> button be a regular button if we want.  Getting the mute LED to DTRT
> >> might be tricky, but modern userspace can probably do it.
> >>
> >> This is almost certainly the approach that does something sensible
> >> with the least code written.  We would just check for HAUM/SAUM on
> >> startup and, if available, set SAUM to "software control only",
> >> force-unmute the mute circuit, force the volume to full, and disable
> >> the fake soundcard.
> >
> > That sounds sensible.  But, we'll still need to handle the mute LED,
> > like we do for the mic-mute LED now?
> 
> Already done, I think:
> 
>         if (led_set_func(TPACPI_LED_MUTE, false) >= 0) {
>             old_vmaster_hook = spec->vmaster_mute.hook;
>             spec->vmaster_mute.hook = update_tpacpi_mute_led;
>             removefunc = false;
>         }

Ah, right, I forgot that we have already both mute LEDs.

> Admittedly, I see some value in having the mute button mute things
> regardless of what userspace is doing, but I don't see *much* value in
> it.  And, arguably, if that behavior is actually desirable, it should
> be available on all laptops, not just ThinkPads.

Yes.


Takashi

Re: Exposing the ThinkPad HW mute switch to ALSA?

[David Henningsson]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On 2014-10-08 02:43, Andy Lutomirski wrote:
> Admittedly, I see some value in having the mute button mute things
> regardless of what userspace is doing, but I don't see *much* value in
> it.  And, arguably, if that behavior is actually desirable, it should
> be available on all laptops, not just ThinkPads.

Things start to get tricky when you think one step ahead and ask 
yourself what outputs the button and the LED really should control. We 
touched the topic briefly when discussing LEDs on the audio meeting last 
year. I'm attaching my presentation for reference.

(The outcome of the discussion about the mic mute LED was "we don't 
know, go ask designers", and well, you probably know the result, as we 
ended up with "The internal card's mics" for the mic mute LED.)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[-- Attachment #2: mic-mute-LED.pdf --]
[-- Type: application/pdf, Size: 30456 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]