[alsa-devel] [PATCH 4/5] ALSA: hda - Implement shared front mic/hp jack for HP Z220

[Takashi Iwai]

At Fri, 30 Nov 2012 01:33:27 +0100,
David Henningsson wrote:
> 
> On 11/29/2012 04:21 PM, Takashi Iwai wrote:
> > HP Z220 with ALC221 codec has a front jack that should work as both
> > the front mic and the secondary headphone.  This patch adds a new
> > mixer enum to change the jack behavior.
> 
> Hmm, in principle I don't like this hack.

I don't like either, but there was some demand for such feature...

> In many machines, both front 
> jacks could probably work as anything (line in, line out, headphones, 
> mic, etc), and that goes for many pins on many machines, and we would 
> end up with a ton of ALSA kcontrols and an incredibly complex parsing 
> machine.

Actually we can (or should) add "xxx Jack Mode" enum to every jack in
future.  See below.

> I would recommend a user to use hda-jack-retask in these cases, instead 
> of cluttering the kernel code.

Well, hda-jack-retask is a nice debugging tool, but it's not intended
for the actual user interface for daily use.  Also, a big missing
piece is the automatic retasking via jack detection as a headphone.

> If you insist though, a slightly more consistent mechanism would be to 
> use the same approach as we did with the single 3-pin jacks (on some 
> Asus machines, IIRC), where selecting the Capture/Input Source would 
> retask the pin, instead of adding a separate "Jack Mode" switch.

I thought of that, too.  OTOH, "xx Jack Mode" enum is already present
for IDT codecs over years.  This isn't used for configuring the I/O
direction of jacks but choosing bias levels.  Why not applying the
same logic for I/O direction switch?

Windows have capabilities to tune each jack as well.  This is a
long-standing TODO, and I think "* Jack Mode" enum is the natural way
to implement it.  (How to let user setting it is another question.
I can imagine that PA could ask user once when a jack is detected.)

About your alternative proposal: the problem by extending the input
source selection is that this jack is supposed to be a front mic jack
as default.  So, this is always listed in the capture source imux.

> Also, the jack detection won't work well with PulseAudio, if I read the 
> code correctly PulseAudio will think a front mic has been inserted 
> regardless of the mode. You have been warned :-)

Yeah, it's a concern.  Currently it's no issue because no capture
source enum is exposed, so PA can't do anything wrong.  But if we
expose the capture source, it may conflict.  One way to avoid it is to
make the capture source inactive on the fly in auto mic mode.
The question is how robust PA is, whether it's screwed up by such a
change...

> Now; if you have a very strong reason why this machine would need this 
> special retask mechanism and all other machines don't, I'm willing to 
> listen...

A strong reason for adding the feature to this machine is that this
has a print on the top of the front mic jack indicating it's a shared
front-mic / headphone jack.  Thus it must behave as advertised.  This
is user's expectation.

If other machines have such a print, the similar method should be
implemented, too.


Takashi