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

[Takashi Iwai]

At Fri, 10 Feb 2012 16:39:46 +0000,
Mark Brown wrote:
> 
> On Fri, Feb 10, 2012 at 05:09:35PM +0100, David Henningsson wrote:
> > On 02/10/2012 04:50 PM, Mark Brown wrote:
> 
> > >>Given that the normal desktop user does not usually look at these values
> > >>these days, I'd say being parser friendly weighs heavier than being
> > >>"normal English".
> 
> > >Not all the world is desktop.
> 
> > The normal end user of the embedded system does not look at those
> > values either.
> 
> There's rather a lot of people who do embedded development and do need
> to look at this stuff, though.  There's a real cost to raising the bar
> for humans to understand things.

Hm, I'm afraid that this is getting apart from the real worth
discussion.  I'm interested in whether "Line-Out" is acceptable
enough, or it's a matter of taste, just like Marmite is acceptable as
the normal English breakfasts.


> > >>I think both naming schemes are good, and I'm not too worried about them
> > >>being too verbose. If we run into names being longer than the string
> > >>length we could back off and drop the location, I guess.
> 
> > >It's a complete pain for actually working with them and doing
> > >development - it renders badly in UIs (think about alsamixer for
> > >example, or people looking at things on 80 column terminals) and isn't
> > >friendly to people typing things in.
> 
> > So your suggestion was, to avoid "Front Headphone" and "Rear
> > Headphone" because the names were too long, and instead have
> > "Headphone" and "Headphone,index=1" and have "Front" and "Rear" read
> > out of a TLV?
> 
> No, some of the information should go in the name but we keep on coming
> up with more and more things to add and when we end up with "Left Silver
> Headset Jack Headphone" or whatever (which would be a fairly complete
> description of half the headset jack on one of my laptops) we probably
> ought to be cutting some of that out.  

Actually, in my very first version, there was no location prefix or
channel suffix but it was only a simple name like "Headphone" with
index numbers.  Then, I faced a problem when trying to integration
with the input-jack layer.  The input-jack doesn't provide the index
number.  So, you can't register the same name correctly.  Thus I tried
to create a unique name string as input-jack id.

Now, looking back to your implementation, the kctl jack is created
with a name string based on the switch type, not from the name string
passed to snd_jack_new() itself.  Why not passing the string as is?
If multiple kctls are needed (e.g. for headset), you can either create
a new name or just create the multiple instances with the same name
but give extra TLVs to identify which type it is.  Or, you can create
an enum control so that both the input-jack and the kctl-jack
correspond as 1:1.

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.

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.

> Though thinking about it duplicating all the individual bits of
> information in TLVs would be helpful to automatic parsing, we could
> possibly even do something clever like make minimal subset names that
> contained only the bits that were unique on a given system if we were
> bored enough.

BTW, I found another issue.  With this implementation, you can't build
kjack ctl without input-jack.  I can work around it for HD-audio by
adding more ifdef, but it'd be ugly...


> Oh, by the way the extcon (Android switch class more or less) code looks
> to be coming along quite well which is going to be a third way of
> getting jack information out to userspace.

Yeah, we enjoy freedom :)


thanks,

Takashi