[alsa-devel] alsactl init - implementation and more..
broonie at sirena.org.uk
Wed Aug 13 17:22:19 CEST 2008
On Wed, Aug 13, 2008 at 04:18:16PM +0200, Takashi Iwai wrote:
> Of course, it's a question how fine-grained each file should be. But
> in general, modifying the default configuration just for adding a new,
> fairly independent item is a bad idea. In my scenario: you want to
> add the support for a new hardware -- fine, just add the file without
> changing anything else. This would make the maintenance a lot easier
Yeah, I can see embedded people liking this too - a relatively small
proportion of machines end up submitting their code to mainline for
various reasons and carrying patches is no fun.
> (imagine you maintain a distro package).
Or use one, for that matter - if you've got local changes then you need
to resolve the conflicts between them and the distro versions on every
> > I'm not sure. The restore action will always overwrite all 'init' values
> > (at least when control identifier list is not changed in the driver).
> > Probably, I would prefer a buildin procedure like 'if restore fails then
> > do init'. What about 'alsactl boot' action name?
> The init makes sense in the case when the driver is updated and some
> new controls. Then the newly added controls are set up properly, then
> the other values are overwritten via restore.
I've not looked at the new code yet but it would be *really* nice to
have a format where only the control names are used.
More information about the Alsa-devel