[alsa-devel] [PATCH 2/2] ALSA: Integrate control based jack reporting with core jack reporting

[Mark Brown]

On Mon, Feb 13, 2012 at 06:40:23PM +0100, Takashi Iwai wrote:
> Mark Brown wrote:

> > With these patches I'm mainly looking for a quick and simple refactoring
> > to get rid of the duplication - once we've got rid of the duplicate
> > driver APIs then we can refactor the internals of the implementation
> > however we like but there's a pretty pressing need to fix the driver
> > API and get all the drivers doing the same thing to userspace even if
> > it's not ideal.

> Hm, then I'd say let's hold on.  Merging this half-baked stuff is
> rather confusing at this point since the use of kctl jack isn't
> targeted yet for ASoC.

> I believe what we need _now_ is to decide the policy (i.e. element
> naming rule and TLV definitions) for kctl jacks quickly.

Now that the kctl jacks are there I'm getting people asking me about it
often enough so I'd like to see it merged.

> > > In other words, if 1:1 mapping isn't needed, we don't have to create a
> > > different name string at all.  Just create "Jack Detect" controls with
> > > different indices and with corresponding TLVs.  This would be enough
> > > (could be even easier) for a machine parser.

> > That'd work I think, though I would create a new control for each
> > physical jack at least just for clarity.

> They are indeed individual ctl elements.  They just share the same
> name and are distinguished by the index numbers.  For the parser
> program, it would be even easier because it needs to look only for
> elements containing the single string.  The rest is the parse of TLVs
> of gathered elements, which would be needed no matter whether we have
> multiple name strings or not.

I think we're mostly agreeing here - what I'd like is to be able to give
each jack a descriptive name which shows up in the control name
("Headset", "Docking Station") along with "Jack" or some other keyword.
The descriptive name could be optional, but it seems nice to put it in
the control name.

> > > And, it seems that there is no standard rule defined for the id string
> > > of input-jack.  If 1:1 model is used, we'd need to define this rule.

> > The input stack doesn't have the same concept of machine parsable names
> > for things that ALSA does (honestly that's pretty unique to ALSA within
> > the kernel) - the names it users are all free form text intended to be
> > meaningful to humans only.

> Yeah, maybe.  But, if you have two headset jacks, how would you
> identify with the current jack stuff...?

You've just got the descriptive name to go on, there's no way to
directly associate it back.

> So, at this point, I can list the following policies for kctl jacks:

> A. all kctls have one name string with different indices.  Each jack
>    is distinguished by the TLV provided to each kctl.

> B. kctls are built with only a base name ("Headphone", "Mic") with
>    different indices and TLVs.

> C. kctls contain unique names ([location] base [direction] [channel])
>    optionally with TLVs

I think I prefer B here with the base name being a descriptive name
(which could often be like the above) that should be unique within the
card, even if the driver just adds numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120213/d9509461/attachment-0001.sig