On Sun, Nov 30, 2008 at 9:22 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > At Sun, 30 Nov 2008 09:10:32 -0800, > Dan Nicholson wrote: >> >> On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: >> > At Sun, 30 Nov 2008 08:22:49 -0800, >> > Dan Nicholson wrote: >> >> >> >> On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: >> >> > I don't know who introduced it, but maybe it was a workaround... >> >> >> >> Yeah, I'm sure it was a workaround, but we're trying to get rid of the >> >> unnecessary ones now. >> > >> > Even for drivers without PM support, alsactl alone is useless. >> > So I suggest you to remove it. >> >> I'm sorry, but why useless? It seems that it would be useful to >> restore state from userspace if the driver isn't doing that on its >> own. > > Read alsactl "alone". Without the combination of module unloading and > reloading, it's useless. So, are you saying that all drivers will maintain their state until they are unloaded? > And, whether you need alsactl in pm script depends on the > implementation. On many distros, loading the sound driver will invoke > "alsactl restore" automatically, thus you don't need it in the pm > side. But, for unloading the module, I guess "alsactl store" would be > needed explicitly in the pm hook. Yes, we don't want to unload the modules at suspend time unless working around problems. And then, I'd suspect a udev or modprobe rule would be more appropriate for restoring state. -- Dan -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
