[alsa-devel] Jack detection on HDA vs SoC

[Takashi Iwai]

At Sat, 4 Feb 2012 14:02:09 +0000,
Mark Brown wrote:
> 
> On Sat, Feb 04, 2012 at 01:20:29PM +0000, Mark Brown wrote:
> > On Fri, Feb 03, 2012 at 06:01:41PM -0800, Dylan Reid wrote:
> 
> > > Is there a plan for the soc code to use the control-based method?
> 
> > Not exactly.  I'm expecting that the new interface will be integrated
> > into the generic ALSA jack support rather than done as a custom thing in
> > the HDA drivers which will mean that anything supporting accessory
> > detect will get support, including ASoC.  This stuff should really be
> > handled in the core rather than in individual drivers, there's also
> > extcon which we'll need to integrate with.
> 
> BTW, the core code I'm talking about is that in sound/core/jack.c but I
> just noticed we also acquired a sound/core/ctljack.c.
> 
> Takashi, we really need to sort this stuff out - it's all getting very
> confusing.  We've got two different bits of code with very similar
> interfaces on the driver side but totally different application layer
> interfaces.  From a driver point of view it's not great to have to tell
> the core the same thing twice and from an application point of view we
> don't have any consistency.

Yep, absolutely.

> Looking at the code I don't understand why ctljack is done separately to
> the rest of the accessory detection - surely we should just have the
> snd_jack code create a control for each thing that can be reported?  I
> can't immediately see a problem with just putting a "Headphone Jack" or
> whatever the naming convention is for these controls on the end of the
> name that we were given for the base jack (probably support that being
> empty).

The simple answer is not to break the things right now :)

In the current release, I left ctljack.c as is before the integration
with jack.c simply because of different use-cases I faced: the
input-jack provides the multiple switches for a single jack while the
current ctljack.c provides only a boolean.  Although the ctljack can
provide an enum instead of a boolean for representing a similar model,
I wanted to get the global overlook and a consensus at first.

Meanwhile, the boolean implementation is enough for most of PC
(especially HD-audio) stuff and the ctljack implementation was
demanded.  Thus I decided to merge the branch for 3.2.

Definitely the integration work is necessary and foreseen.  The
biggest problem my workload for other tasks.


thanks,

Takashi