On Fri, Jan 09, 2009 at 01:20:38PM +0000, Liam Girdwood wrote:
On Fri, 2009-01-09 at 01:02 +0000, Mark Brown wrote:
Right now my feeling is that we probably want to do at least some scenario stuff in kernel space and that what's sensible for a given
My feeling is that kernel based scenario really should be minimal to non existent depending upon machine. If it has to be implemented then it must be consistent across all devices (probably worth creating a sound/core/scenario.c for others to use).
Yes, that's pretty much what I'm thinking. The kernel should have anything required to prevent hardware damage in it but beyond that it's getting debatable.
It also seems useful to have some support for doing a fixed rename of controls in machine drivers to allow things like renaming of outputs and inputs to match the connections on the machine.
I'd probably be willing to see a small amount of additional scenario code in kernel space for cases where it's clear that the hardware can only run in a very small number of scenarios due to the limited features it has, especially if it ties in with stuff that needs to be done to prevent hardware damage. It looks like this device may well fall into that sort of use case.
Imho it's far better to do most scenario in userspace due to increasing driver complexity and slow driver scenario development speed (remember the OSS driver pain involved with this). Userspace will additionally
It's also policy, which on general principle shouldn't go into the kernel anyway. With devices like the OpenMoko it looks out you pretty much need to have any to any routing available to user space anyway to cover all the use cases people have so you have to have a way of doing scenarios in user space.
give us a consistent API for applications and hopefully much better adoption (esp if merged into alsa-lib / salsa).
Or adopted by things like the FSO stack.