Re: Jack event API - decision needed

Takashi Iwai
2011-06-28T16:35:34Z

At Tue, 28 Jun 2011 17:27:15 +0100,
David Henningsson wrote:
>
> On 2011-06-27 13:07, Mark Brown wrote:
> > On Mon, Jun 20, 2011 at 03:37:25PM +0200, David Henningsson wrote:
> >
> >> 1) We're continuing the path with /dev/input devices
> >
> >> 2a) We'll rewrite these devices to be read-only ALSA mixer controls
> >
> >> 2b) We'll rewrite these devices to be something within ALSA, but not
> >> exactly mixer controls.
> >
> >> For options 2a) and 2b) I guess the existing /dev/input thing should be
> >> deprecated and/or removed. So part of decision should maybe be based on
> >> information about how widespread the usage of these devices are
> >> currently...?
> >
> > So, this discussion seems to have ground to a halt.
>
> Yes, unfortunately, and without a clear consensus. That puts me in a
> difficult position, because I'm trying to get the job done. And very
> preferrable, in the next release of Ubuntu (which is to be released on
> October this year). I've been talking to a few of my colleagues here at
> Canonical, and here's how we reason currently:
>
> We have the input layer. We also have a set of patches for supporting
> this in PulseAudio (although currently unmerged and I'm not sure about
> their current quality/state).

So, the targets are already defined, i.e. what information is actually
required? This wasn't very clear to me until now.

> We don't have the alternative Alsa Control API discussed in this thread.
> Without taking a stance of whether that would be a better solution or
> not, designing it will take some time - somewhat depending on the set of
> problems we're aiming to solve. Regardless, it will definitely not reach
> the 3.0 kernel (which is what we will ship in the next release of Ubuntu).

If only the same functionality is required as currently done in the
input-jack layer, re-implementing the jack-detection elements in ALSA
control API is pretty easy. It means that the control element would
have some jack name with a location prefix or such, reports the
current jack status, and notifies the jack change. That's all.
Optionally, it can have a TLV data giving the HD-audio jack
attribute, too.

As already mentioned, the difficulties of implementation mainly
depends on the requirements. If just a flat array without structural
connection is enough, it's easy, of course.

But, it definitely won't reach to 3.0 kernel. So, maybe this won't
help in your case, anyway...

thanks,

Takashi