[alsa-devel] alsactl init - implementation and more..

[Jaroslav Kysela]

On Wed, 13 Aug 2008, Takashi Iwai wrote:

> At Wed, 13 Aug 2008 16:04:47 +0200 (CEST),
> Jaroslav Kysela wrote:
> > 
> > > The card-specific configs shouldn't be read from 00main, but read from
> > > its file, i.e. 50hda.  That is, the config files are to be simply
> > > added / removed without modifying the existing file.
> > 
> > I'm not sure if it's useful for our purposes. The 00main also contains
> > some "global" configuration (like SYSFS_DEVICE setup and more variables 
> > can be added in future) and my initial (not saying that it's optimal) 
> > configuration assumes that first file lookup is a driver name.
> > 
> > If you like to add extra configuration files in a directory, I would 
> > enhance 'INCLUDE' executer code to check, if the source path is directory 
> > and then include all files from it. But for the standard "database" 
> > purposes, I don't see a reason to check every file and skip contents of 
> > large files just after parsing first lines with false condition.
> 
> 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
> (imagine you maintain a distro package).
> 
> If scanning too many files really matters, then they can be
> concatenated at appropriate timing.

My idea is to have a default database (which should be quite optimized for 
parser) and distro specific addons install to a directory as you 
suggested. So, something like (in alsactl init syntax) in 00main:

INCLUDE="addon"

Tree:

/usr/share/alsa/init/addon/Acer_XY80
/usr/share/alsa/init/addon/Acer_ZY91

etc...

The 00main file might remain (just to handle global specific 
configuration).

Eventualy, another INCLUDE can be placed before the default database
processing to override the default database.

> > > Another would-be-nice feature is one command to do both init and
> > > restore.  First initialize the hardware, then restore (overwrite) the
> > > setting from the asound.state if already eixsts.  This is what udev
> > > needs to call.
> > 
> > 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.

Upgrading a driver is quite specific process. In this case would be 
probably better to read saved state and compare it to the actual driver 
controls. If something differs, call init and then restore with force 
flag. At least, the init procedure would be skipped (almost every boot 
time) if all controls are present in the state file.

So, I'm proposing this 'alsactl boot' behaviour:

1) read /etc/asound.state
2) if the state does not exist run 'alsactl init' and exit
3) if the state exists but controls do not match these in driver, run 
   'alsactl init'
4) run 'alsactl restore'

Opinions?

					Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.