Neo1973 WM8753/Alsa Configuration

Mark Brown broonie at opensource.wolfsonmicro.com
Mon Oct 6 12:22:36 CEST 2008


On Sat, Oct 04, 2008 at 12:39:26AM +0200, Joerg Reisenweber wrote:

> Also I'm pretty sure the "user visible control name" isn't exactly what you 
> get to see in alsamixer for example. Furthermore they are often wrong as they 

The user visible control name might get truncated due to limitations in
ALSA and it might get a prefix added to it but other than that it should
be presented directly - should certainly be good enough for searching.

> don't regard our particular hw-setup, where GSM-mic sensitivity is something 
> like "mono sidetone playback volume" or such weirdness.

Right, there's a certain assumption there that you'll be able to cross
reference with the design.  There have been efforts to fix this for end
user applications but not much for people working on scenario configuration
- there's much less call for doing it there, quite a few people would
find it confusing.

> The situation resembles using a "genuine PS/2 mouse" driver for a synaptics 
> touchpad. I really don't think there is any value or sane rationale behind 
> using a generic upstream driver for a very OM-specific hw-design, the usual 
> way for all hardware is manufacturer of device creates tailored-to-suit 
> drivers for their product, admittedly based on chip manuf's generic chip 
> driver sources usually.

That's what everyone used to do in Linux - what happened was that you
ended up with a pile of drivers, all replicating the same control for
the same chips but usually missing out bits of it.  Any kind of update
or improvement had to be made to each driver independently which was
very wasteful, causing a lot of duplicated work.

It's worth remembering here that the way things work in the Linux kernel
when you're trying to upstream (overall, not just for audio) is very
different to how things work in proprietary OSs.  Rather than forking
off a BSP for a particular system as you would with a proprietary OS all
systems work from the same kernel code.  System-specific changes to
generic drivers are strongly frowned on since they don't scale well, so
generic drivers that need such modifications don't go over too well.



More information about the hardware mailing list