[alsa-devel] RFC: Jack-detection control elements on HD-audio

Takashi Iwai tiwai at suse.de
Fri Jul 3 07:32:21 CEST 2009

At Thu, 2 Jul 2009 17:27:52 -0500,
pl bossart wrote:
> Takashi,
> I looked at your code for jack sensing and I am really confused on how
> these evolutions will be used.
> It seems to me these additions with the new control apply only to the
> HDAudio case. Meaning if Lennart modifies PulseAudio to read the jack
> sensing information from the new control, Lennart's code will not work
> on embedded platforms which rely on ASoC and plain snd_jack_report /
> input layer (or any non-HDAudio based solution for that matter), and
> we don't have a generic way to providing the jack information to
> PulseAudio.
> I had a private discussion with Mark where he stated that ASoC would
> not change, and would automatically benefit from this additional
> control. That does not seem to be the case.
> Either I am missing something (not an unlikely scenario, I am
> light-years from my comfort zone here) or everyone is on a different
> wavelength.

The features I want to implement (for HD-audio, so far) are just using
the existing framework.  That is, you can implement pretty easily on
any drivers that can detect the jacks as well.  It's just like adding
new mixer elements.  Once after other drivers need it, we can move
the helper functions to the common layer.

In other words, the jack reporting over control API is generic, in the
sense as generic as mixer controls.  And, it doesn't conflict with the
existing jack input layer.


> Thanks for your feedback,
> Cheers
> - Pierre
> On Fri, Jun 19, 2009 at 5:08 AM, Takashi Iwai<tiwai at suse.de> wrote:
> >> It'd be nice to keep the input API interface as well - one of the
> >> reasons I carried on with the existing input interface was that the
> >> existing userspace stuff I found was using the input API in one way or
> >> another.  In the embedded space it appears to have often been convenient
> >> for people to read jack sense from a GPIO as part of a GPIO keyboard
> >> they're already using which was part of the reason it was never really
> >> joined up with ALSA in the past.
> >
> > Don't worry, it's kept as is.  The control elements are just
> > additions.

More information about the Alsa-devel mailing list