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. _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
