Re: [PATCH] ALSA: hda/jack - Also add jack kctls for Conexant codecs

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Thu, Dec 22, 2011 at 02:55:57PM +0100, Takashi Iwai wrote:
> Mark Brown wrote:

> > A pure addition can still cause problems as we roll out the same
> > interface into other drivers, for example if there's assumptions that
> > aren't generally true.

> In later future, yes.  But I was talking about 3.3 kernel.

Once we've got a userspace interface we're pretty much stuck with it...

> > I'm guessing that as this is just a simple boolean each jack will have a
> > series of controls like "Headset Jack Headphone" and "Headset Jack
> > Microphone" or whatever and userspace should match them all together in
> > the same way that it does for Volume and Switch controls?

> My current assumption is so, too.  OTOH, if a single jack must provide
> several values inevitably, it may take an integer or an enum, in
> theory.  But I think (and hope) this wouldn't happen.

Supporting multiple objects on a single jack is a very basic requirement
in order to support headsets (which exist on PCs as well, the MacBooks
for example) - we can usually distinguish between at least headset and
headphone.  I think if we're going to do this via a single multi-state
control rather than a series of booleans it'd need to be an enum for
usability ("an object of type 2!"), Android uses integers and it's
pretty miserable for usability.

> >  That sounds
> > like it'll work well, we just need to define some strings for standard
> > jacks and conections.

> Yeah.  Unfortunately this standardization isn't always trivial,
> especially when multiple jacks are present with the same type...

I was thinking more about the things you might detect rather than the
jacks, that's a much more tractable problem.

> My idea is to give some association between this jack kctl and another
> kctl, in a simple way like TLV.  But it's likely a new year's dream.

Associating the jacks with the audio routes is definitely a separate
problem.