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: > > 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' That would work although init can be done always when you run alsactl restore anyway. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
