At Wed, 13 Aug 2008 19:26:25 +0200 (CEST), Jaroslav Kysela wrote:
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...
They should use number-scheme, too.
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.
Yes, sometimes we need a replacement and sometime an additional setup.
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.
FYI, the force flag is already used as default in the current alsactl.
So, I'm proposing this 'alsactl boot' behaviour:
- read /etc/asound.state
- if the state does not exist run 'alsactl init' and exit
- if the state exists but controls do not match these in driver, run 'alsactl init'
- run 'alsactl restore'
That would work although init can be done always when you run alsactl restore anyway.
Takashi