From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B44CC433E0 for ; Wed, 10 Feb 2021 11:27:27 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6EBA064E2A for ; Wed, 10 Feb 2021 11:27:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6EBA064E2A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id A961016CE; Wed, 10 Feb 2021 12:26:34 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz A961016CE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1612956444; bh=yiEOeutAwah17LpKAJCd0bCXWUIVIqQ5DI3b77YOaqA=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=sc5aAToe2AGytTG/I/dHXiXpjf5RM3jHTedgoFuF6ukp12X99GfJDfEJg0rSbXSu+ P+KFebmQY2KFKWLCOhuK3mgqNo2bSDf7EFLiQ8TrxDMC8HEcDA3CVqqEZeWpfA9wDq zAoCHddTubVLlymw6GHLnfBX5uYLIBFls4NjFwZ4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 3BA59F80169; Wed, 10 Feb 2021 12:26:34 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 38A48F8022B; Wed, 10 Feb 2021 12:26:32 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 8C877F80165 for ; Wed, 10 Feb 2021 12:26:27 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8C877F80165 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0935FAD57; Wed, 10 Feb 2021 11:26:26 +0000 (UTC) Date: Wed, 10 Feb 2021 12:26:24 +0100 Message-ID: From: Takashi Iwai To: Takashi Sakamoto Subject: Re: [PATCH] [RFC] ALSA: control - add generic LED API to sound core routines In-Reply-To: <20210208223443.GA258185@workstation> References: <20210207201157.869972-1-perex@perex.cz> <3bc1b151-68ce-8408-aff1-aeba2e6fe4c3@perex.cz> <20210208223443.GA258185@workstation> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Hans de Goede , ALSA development , Perry Yuan X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Mon, 08 Feb 2021 23:34:43 +0100, Takashi Sakamoto wrote: > > Hi, > > On Mon, Feb 08, 2021 at 05:33:02PM +0100, Takashi Iwai wrote: > > > > Also, are those new access flags exposed to user-space intentionally, > > > > so that user-space gets some information? > > > > > > Yes, it's one benefit, the second benefit is that we can create user space > > > controls for hardware which does not have any switch / volume controls for the > > > given path. > > > > > > An example is the AMD ACP bridge with the simple digital microphones. We can > > > use alsa-lib's softvol plugin to control the volume for this and it would be > > > nice to mark this user space control with the mic mute LED flag. > > > > OK, makes sense. > > I have a concern about the usage of access flag for such kind of > hardware specific stuffs (LED dedicated to specific audio control) > since it's not enough hardware abstraction. > > In my opinion, for the case, developers for in-kernel driver tend to use > specific name for control elements (or prefix/suffix of the name). Adding > new access flags for it seems to be overengineering against the original > purpose. > > > The patch itself includes some remarkable ideas that: > - introduction of association between control elements > - analyzing current status of the association (then operate LEDs) > - communication to userspace stuffs about the association > > (here I carefully avoid usage of word 'topology'.) > > The association itself seems to be useful when cooperating use case manager > of alsa-lib. I guess that the kind of framework designed for the association > is preferable instead of the patch tight-coupled to LED stuffs. > (And some subsystem already attempts to implement such framework into kernel > land, e.g. media controller devices in media subsystem.) > > > In another side, I guess that the reason to supply the association to > kernel land is to use 'ledtrig_audio_set()' kernel API. If userspace > stuffs find target LEDs and operate them via userspace interface, > the association could be in userspace. I think it better to investigate > for the direction since I can imagine that the introduction of association > to kernel land brings much codes into kernel land to support wide-variety > of hardware (and going to be obsoleted according to lifetime of actual > hardware sooner or later). Sakamoto-san's comments made me reconsidering of the situation again. The user-space access like via sysfs was my original idea when the mic mute LED issue came up for AMD ACP driver in the past. One problem is the permission. The r/w control over sysfs is for root, and we want for a normal user. This might be solvable via loginctl or such and adding the dynamic permission via ACL. I didn't investigate enough yet. Takashi