[alsa-devel] HDA regression on Fujitsu S7020 laptop (ALC260 codec)

[Jonathan Woithe]

On Thu, Jan 03, 2013 at 11:39:33AM +0100, Takashi Iwai wrote:
> At Sat, 29 Dec 2012 00:22:07 +1030,
> Jonathan Woithe wrote:
> > 
> > Having been running kernel 3.3.5 for a while, I decided to upgrade to 3.7.1
> > tonight.  Unfortunately there have been a number of HDA-related regressions
> > between these two kernels when running on a Fujitsu S7020 laptop which are
> > clearly related to the HDA rewrite which has been going on recently.  This
> > laptop utilises the Realtek ALC260 codec.
> > 
> > Testing was initially done with alsa-lib 1.0.24 and alsa-utils 1.0.24.  I
> > upgraded to version 1.0.26 of both but the behaviour remained the same under
> > 3.3.5 and 3.7.1.
> > 
> > Under 3.3.5, sound works perfectly.
> > 
> > Under 3.7.1 there are a number of regressions:
> > 
> >  - there is no alsamixer control for the internal speaker.  I have a "PCM"
> >    volume control which appears to do nothing.  Previously there was a
> >    speaker control, the PCM control affected every output (from memory), as
> >    did the master volume.
> > 
> >  - no audio comes out of the internal speaker regardless of the "auto mute"
> >    setting.
> > 
> >  - there are no pin mode (re-tasking) controls for the mic or headphone jack
> >    in alsamixer.  On this laptop the mic jack should have various bias
> >    options as well as line-in.  The headphone jack should include headphone
> >    (aka output amplifier on), line-out (output amplifier off), line-in and
> >    mic options.
> > 
> > The second ADC does show up in alsamixer as a second capture device, but
> > probably due to the lack of retasking support it is not possible to select
> > the headphone jack as an input option.
> 
> The jack retasking of the headphone input is still an open issue.
> I can provide a patch to add the support via "Headphone Jack Mode"
> enum, but David didn't like that approach.

What alternative has been proposed?  On this laptop the headphone jack can
be retasked as an input and there doesn't appear too many other options
other than to expose this to the user via a mode control of some kind. 
Similarly, the mode of the "line in" jack can also be changed between
various "mic" modes with different biases and - most importantly for me - a
line in mode.  JFTR I also recall that on other laptops the "line in" jack
could be set to function as an output (this doesn't work on the S7020 due to
the circuit used for that jack).

> > Audio does come out of the headphone jack.  However, as noted above it is
> > not possible to switch this from headphone to line-out.  The volume of the
> > headphone output is affected by the "master" and "headphone" volume
> > controls.
> 
> OK, this should be added similarly via "Headphone Jack Mode" enum.

Agreed.  But if a "Headphone Jack Mode" enum is not the preferred option,
how else can we make this happen?

> > The inability to set the pin modes is a showstopper for me - I need to be
> > able to do this and thus will be stuck on older kernels until this is fixed.
> > 
> > At the end of this post I have included the /proc/asound/card0/codec#0
> > output under 3.3.5 (which works well) and 3.7.1 (which is broken as
> > described above).
> > 
> > What needs to be done to restore the functionality for the S7020 that has
> > been working for years?  It seems that some form of model quirk needs to be
> > ported into the new HDA framework from earlier kernels, but since this sort
> > of thing appears to have been removed with the rewrite (at least for realtek
> > codecs) it's difficult to see where to begin.
> 
> At best, please give alsa-info.sh outputs on both old and new kernels.

I will post these in a follow-up within a few minutes.

> We won't add any longer too much machine-specific code.  In the long
> run, (most of) all codec drivers will be merged to a single driver.
> So, let's fix the easier one, the auto-mute breakage at first, and
> proceed to add the missing mixer enums for introducing the finer jack
> retasking.

Ok.  Personally I don't care for auto-mute at all: I need to be sure that
the speakers will never output audio even if the headphone jack is pulled. 
That is, my normal mode of operation will be to have auto-mute disabled
which should - I assume (once the bug is fixed) - produce separate headphone
and speaker mixer controls as it always has.

As a general comment, sometimes it is essential to maintain full manual
control over the mixer hardware so it doesn't get automagically reconfigured
for some odd reason in the middle of an event, resulting in unintended audio
routing.  I certainly don't mind the provision of a more automated system
which works for the common case, so long as it doesn't result in the removal
of manual control for those of us who need it.

Regards
  jonathan