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=-5.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 50F38C433E0 for ; Wed, 24 Feb 2021 17:59:00 +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 A82C064ECE for ; Wed, 24 Feb 2021 17:58:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A82C064ECE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=perex.cz 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 357D1166A; Wed, 24 Feb 2021 18:58:06 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 357D1166A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1614189536; bh=PWFdGHPsj1w5iTVQOO2XpbUTn4/QoLOAgRKgO4mmAgk=; h=Subject:To:References:From:Date:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=t5ER5Uy8+KnnFcZjESNYv2i3xfj7taJMz5tsEHI6JieEVI9Y7LhGpNUekHaqrFHEW jMga1bkjVF+1ryQR+d2/8rav9egcD9B6psnY6w4NZCQtUAfa/LdOEn9S/lJjZNmuV8 ENRgfEhvm/RFd2xHvCYNqmHPrg/usphRlQXydoqc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 9F1BFF80129; Wed, 24 Feb 2021 18:58:05 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 2F13AF80161; Wed, 24 Feb 2021 18:58:03 +0100 (CET) Received: from mail1.perex.cz (mail1.perex.cz [77.48.224.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 645E9F80129 for ; Wed, 24 Feb 2021 18:57:55 +0100 (CET) Received: from mail1.perex.cz (localhost [127.0.0.1]) by smtp1.perex.cz (Perex's E-mail Delivery System) with ESMTP id CD8EBA0040; Wed, 24 Feb 2021 18:57:49 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.perex.cz CD8EBA0040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perex.cz; s=default; t=1614189469; bh=VUDsV98YQPhK0IRpcISL/MPX1gHQFJyWp45ADQQTES0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ny1iKUUm29HuAGiF1V6VMdJ8EOlji0wpmgvPkVKTpML+dO8kzcbMmgOA+Q0DUyAJX UF4G6QhxKVftzkmbhUpj/z7E+g6f/vng8U8XaFTcHJqfu4IlBxK9CvAQ4Vwx4Uv8kh mNNQEB/p8nNklnijn2NKDHpp0WicVAzuetHP94dM= Received: from p1gen2.localdomain (unknown [192.168.100.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: perex) by mail1.perex.cz (Perex's E-mail Delivery System) with ESMTPSA; Wed, 24 Feb 2021 18:57:42 +0100 (CET) Subject: Re: [RFC 2/2] ASoC: rt5670: Add LED trigger support To: Takashi Iwai References: <20210215142419.308651-1-hdegoede@redhat.com> <20210215142419.308651-3-hdegoede@redhat.com> <20210223134506.GF5116@sirena.org.uk> <578b1ee3-f426-c5b5-bc78-5a91108ebdc8@redhat.com> <20210223140930.GH5116@sirena.org.uk> <5c6a21c1-7107-3351-25be-c007b0b946d3@perex.cz> <776b4ad9-2612-b08a-cb76-c3e1ce02388a@perex.cz> <4574088a-4676-131a-0065-499a516f80ae@perex.cz> <03068e15-2157-3ae6-ffd6-7ec315bb49a3@perex.cz> <9c74e8de-769c-cd98-3944-85bd75bc840b@perex.cz> From: Jaroslav Kysela Message-ID: <3c262ea6-2313-3af8-60ae-d59ae8be262d@perex.cz> Date: Wed, 24 Feb 2021 18:57:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Cc: Oder Chiou , alsa-devel@alsa-project.org, Liam Girdwood , Hans de Goede , Mark Brown , Bard Liao 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" Dne 24. 02. 21 v 13:42 Takashi Iwai napsal(a): > On Wed, 24 Feb 2021 13:08:55 +0100, > Jaroslav Kysela wrote: >> >> Dne 24. 02. 21 v 12:43 Takashi Iwai napsal(a): >> >>>>> So far, a user control is merely storing the value, let read/write via >>>>> the control API. That's all, and nothing wrong can happen just by >>>>> that. Now if it interacts with other subsystem... >>>>> >>>>> A more serious concern is rather the fragility of the setup; for >>>>> enabling the mute LED control, you'd have to create a new user-space >>>>> control, the function of the control has to be ignored by some >>>>> application and some not, etc. This has to be done on each machine >>>> >>>> You're using "ignore", but as I explained before, the user space switch will >>>> be used in the whole chain: >>>> >>>> capture stream -> >>>> alsa-lib mute switch / silence PCM stream -> >>>> PA mute switch / silence PCM stream >>>> >>>> So PA can use this switch like the traditional hardware mute switch. >>> >>> Does it mean PA would work as of now without any change? Or does it >>> need patching? >> >> Yes, no PA modifications are required with my mechanism. The PA will just see >> the new user space control - mute switch - created in alsa-lib - which will be >> synced the internal PA path mute state like for the hardware mute >> switch. > > OK, but how would we create and manage the user control element? And > why it has to be user control? The softvol or alsactl can create the user control element. The alsa-lib softvol plugin and PA can silence stream according the state. I see your point to create this control in the kernel space, but any other name than "Mic Capture Switch" (in the ACP case) will be misleading for users, because the user-space does the appropriate real silencing job instead of hw. And if we create "Mic Capture Switch" in the kernel space, it may be misleading for applications (they can think that there's hardware mute control). Perhaps, we can create "Mic Phantom Capture Switch" in kernel which may resolve both problems (no hw mute information + no user confusion). Jaroslav -- Jaroslav Kysela Linux Sound Maintainer; ALSA Project; Red Hat, Inc.