[alsa-devel] [PATCH 2/2] ALSA: Integrate control based jack reporting with core jack reporting
broonie at opensource.wolfsonmicro.com
Fri Feb 10 17:39:46 CET 2012
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.
> >>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.
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120210/07ae9fc0/attachment.sig
More information about the Alsa-devel