At Tue, 09 Apr 2013 17:52:23 +0200, Jaroslav Kysela wrote:
Date 9.4.2013 14:47, Takashi Iwai wrote:
At Mon, 8 Apr 2013 14:51:54 +0200 (CEST), GIT server wrote:
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "ALSA utilities repository".
The branch, master has been updated via e05b903b1fb16e967d838edac408304cd4470fee (commit) from 46cb355d4ff41c8065b02644b0534ab42d16cb72 (commit)
Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below.
- Log -----------------------------------------------------------------
commit e05b903b1fb16e967d838edac408304cd4470fee Author: Jaroslav Kysela perex@perex.cz Date: Mon Apr 8 14:49:31 2013 +0200
alsactl: move systemd config to the daemon mode Signed-off-by: Jaroslav Kysela <perex@perex.cz>I'm not thrilled by the silent default behavior change like this. This will affect all systems using systemd from now on.
I understand the reason behind it, but I wonder whether it's an overkill. Yet another daemon, unconditionally no matter whether hotplug or not? Hmm...
The question is, how we can detect the hotplug scheme. Almost all systems have USB today and laptops have PCI express card slots, so.... Fedora has the systemd configs in the alsa-utils package. A removal of this package is sufficient do disable the daemon.
Yes, but then this would break the formerly working environment, too.
Eventually, we can save the state periodically using cron (without the changes tracking), but my measurement is that the alsactl daemon eats approx. 150kb of memory.
I'm not concerned about alsactl memory footprint so much. But having another daemon unconditionally just to save/restore the mixer status is a question.
Some other quick ideas:
- make the static/hotplug schemes depending on an environment variable passed through the bootloader
- another two packages on top of alsa-utils with two configs
Manageable, but maybe will become a bit messy...
- save the last state inside the driver and offer it to the userspace upon the card removal (seems overkill)
This won't be that bad, I think. But, accessing the information after removal is the problem, after all. The device and proc files are removed at disconnection, so user-space can't access it. Otherwise the normal "alsactl store" should have worked. So this can't be a card-basis interface.
A possible w/a would be that we can keep some stable ctl lists and provide it as a (one-time) death message from a global proc or a sysfs file, for example. Then we don't need periodical sync.
Whether this is a better option? I dunno, honestly, too...
- run multiple daemon instances per hotplug card; the question is how to detect the static card in the system (perhaps checking the PCI config?) to avoid the daemon startup for those static cards
Yeah, when thinking a PCI hotplug, it's not easy.
Takashi