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

[Takashi Iwai]

At Wed, 22 Feb 2012 20:55:30 +0000,
Mark Brown wrote:
> 
> On Wed, Feb 22, 2012 at 09:35:08PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > As I've *repeatedly* said the idea was to prefix the name once we'd got
> > > stuff merged into the same file (which means ripping out the HDA
> > > specific code)
> 
> > Even if so, it can't be merged until this prefix stuff comes in.
> > As mentioned, otherwise it conflicts.
> 
> Well, yeah.  But if there's an insistance that the new ABI is reworked
> as well then it's not worthwhile.  It's a pretty simple change to make,
> I just didn't want to faff around with the HDA code to discuss the core
> interface - IIRC I mostly posted the patch to make it clear that both
> APIs just use sets of booleans.

OK.

> > Alternatively, deprecate CONFIG_SND_HDA_INPUT_JACK.  This is another
> > option.
> 
> I think we should do that anyway, just unconditionally enable the
> feature.

OK.

> > Meanwhile, we can mark it deprecated now as we provide an alternative
> > solution in 3.3 frame.  Then drop it in 3.4 or 3.5 where your patch
> > comes in.  THis sounds feasible.
> 
> We're well past the point at which we can change 3.3 substantially.

Yes, but it's not too late to put a DEPRECATED marker in Kconfig right
now, at least.  It's no removal yet, so no problem for 3.3.


> > > It seems like it's a bit late to worry about the naming scheme to that
> > > extent given that the existing ABI has already managed to get into one
> > > kernel release and looks like it's also going to get into 3.4 as well.
> 
> > Which ABI?  The kctl jack hasn't been in released kernels yet.  It was
> > first merged in 3.3.  So I really want to fix up the naming rule as
> > soon as possible before 3.3 release.  For example, with or with
> 
> We're pretty committed to what's in 3.3 though.  If it's just the hyphen
> that's a fairly meaningless difference in terms of the stuff I'm talking
> about, it's trivial to change.  But if you guys decide to go with things
> like adding TLV information or whatever then that's more involved and I
> can't see that getting in at this point, we'd need to remove the kctl
> jacks from the userspace interface for 3.3 or accept churn.

As I showed, the implementation case C, with the verbose name string
and _optional_ TLV, doesn't conflict with both the current HD-audio
code and your future patch.  That is, it can be well "Mic" if it's a
single object.  First when you need to distinguish multiple items or
enumerate with attributes, you can choose either the prefix/suffix in
the name string or the base name with a TLV info: "Rear Mic" is
equivalent with "Mic" with TLV_POS_REAR.

This looks like the most feasible option to me.

> It did also make it out in the last alsa-driver release IIRC.

Bah, the alsa-driver was released by some reason I don't know of.

I really think the release schedule must be defined in a more strict
but easier way.  For example, just release alsa-driver at each time
the kernel is released.  It allows user of the older kernel to run the
driver on the latest kernel (not the latest development version!).

Well, it's another topic, and should be discussed in a different
thread...

> > hyphen.  It's an easy task to fix in the code once when decided.
> 
> I mostly agree, I'm pushing to merge now because it seems like we can
> make the change before or after merging the APIs and I don't want to get
> to the merge window without the two interfaces being brought into line
> because there's still ongoing discussion of exactly what the userspace
> interface for the control jacks should look like.

Right.

> > > Right now the only tractable fix I can see is to implement something
> > > approximating the HDA ABI in ASoC but that just makes things even worse
> > > from a maintability point of view.
> 
> > Well, as I already wrote, the prefix and suffix are supposed to be
> > optional.  So, the current HD-audio implementation doesn't block your
> > interpretation in jack.c by itself.  The only blockages are that the
> > jack.c implementation doesn't provide enough for HD-audio requirement
> 
> So when I submit a patch removing the kctl jack support from HDA in
> favour of something along the lines of the current code you'll be OK
> with that so long as there's also something there to use the card naming
> (I'd expect I'd end up submitting that as a followup patch for the sake
> of making the individual patches clearer)?

If the patch will cover the missing pieces, i.e. filling the location,
the channel and the multiple indices, I'm fine to remove the current
hd-audio kctl jack code, yes.


thanks,

Takashi