From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaroslav Kysela Subject: Re: [alsa-cvslog] [ALSA GIT]ALSA utilities repository branch master updated. v1.0.26-26-ge05b903 Date: Tue, 09 Apr 2013 18:38:31 +0200 Message-ID: <51644407.9050503@perex.cz> References: <20130408125154.6264F2651CD@alsa0.perex.cz> <51643937.5020602@perex.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail1.perex.cz (mail1.perex.cz [77.48.224.245]) by alsa0.perex.cz (Postfix) with ESMTP id EF7C2265E50 for ; Tue, 9 Apr 2013 18:38:31 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org Date 9.4.2013 18:11, Takashi Iwai wrote: > 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 >>>> Date: Mon Apr 8 14:49:31 2013 +0200 >>>> >>>> alsactl: move systemd config to the daemon mode >>>> >>>> Signed-off-by: Jaroslav Kysela >>> >>> 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. Yes, it is. But it looks like the best (or at least easiest to manage) idea to solve the hotplug issues for the moment and we can optimize things later. >> Some other quick ideas: >> >> - make the static/hotplug schemes depending on an environment variable >> passed through the bootloader This variant seems most easy to implement using ConditionKernelCommandLine or ConditionPathExists (this second option may be probably better - a configuration file in /etc/alsa or so to change the state management behaviour looks good). >> - 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. I will add the ConditionPathExists=/etc/alsa/state-static.conf and ConditionPathExists=/etc/alsa/state-daemon.conf conditions and put back the old static config files, if no better idea is offered. Jaroslav -- Jaroslav Kysela Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.