[alsa-devel] Restore state around suspend/resume
dbn.lists at gmail.com
Sun Nov 30 18:30:37 CET 2008
On Sun, Nov 30, 2008 at 9:22 AM, Takashi Iwai <tiwai at suse.de> 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 at suse.de> 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 at suse.de> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Alsa-devel