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=-2.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 DED37C5DF63 for ; Wed, 6 Nov 2019 17:05:11 +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 8B6EF2173E for ; Wed, 6 Nov 2019 17:05:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="ZpLGrSYu"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=perex.cz header.i=@perex.cz header.b="dR1hF1AQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B6EF2173E 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 C2EEF1688; Wed, 6 Nov 2019 18:04:18 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz C2EEF1688 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1573059908; bh=n2bWbjC2hi5iUgawe65ivjeZ0xuDDWGd7BhXt8zgtQk=; h=To:References:From:Date:In-Reply-To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ZpLGrSYuZjmdSSspzNCakyPd0/AeHjGNIEgWpptC2h2lwKT1lA+u14NDjBVIUdfiV nDJBcngY4RlnanCkYSmo7weeYsz9zMi5oNQfjKRgBhDLOVsO/F+nqi/sasY/LZ6ahy MztTLWQWl7W5LgIY/Q4oZVdSBrKoHBx4/5MqzYFQ= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 48134F80321; Wed, 6 Nov 2019 18:04:18 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 4738CF8015B; Wed, 6 Nov 2019 18:04:17 +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 3582CF8015B for ; Wed, 6 Nov 2019 18:04:13 +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 3BA1CA0040; Wed, 6 Nov 2019 18:04:13 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.perex.cz 3BA1CA0040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perex.cz; s=default; t=1573059853; bh=3J5dUTUPCywDYJbmnh/vMnIrub4HgQBaMl6TTrsQRpw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dR1hF1AQfmJtgfD9cmnHhGf7hHsh9XZCd6JSJL0OvIDZzc2jR9nMB99yqKZZMGOEP 2Bqja1eoZqpyoKvBoUdltdcqmorlgC0nGXRjgMOpHod51qPzjoGvzEpQ3PVEvx3H0U jOntfBcEHQCMjv6X1kUgsMheBZ5gIFxbW9xhqXXM= Received: from p50.perex-int.cz (unknown [192.168.100.94]) (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, 6 Nov 2019 18:04:10 +0100 (CET) To: Jaska Uimonen , Kai Vehmanen References: <6dcc3e0d-0df5-90cf-220f-59253d3b5c7c@perex.cz> <140d987f-280a-309a-d09c-fa4b210563db@perex.cz> <1573048312.40545.9.camel@linux.intel.com> From: Jaroslav Kysela Message-ID: Date: Wed, 6 Nov 2019 18:04:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <1573048312.40545.9.camel@linux.intel.com> Content-Language: en-US Cc: ALSA development Subject: Re: [alsa-devel] UCM extensions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Dne 06. 11. 19 v 14:51 Jaska Uimonen napsal(a): > On Wed, 2019-11-06 at 14:10 +0100, Jaroslav Kysela wrote: >> Dne 06. 11. 19 v 12:50 Kai Vehmanen napsal(a): >>> Hi Jaroslav, >>> >>> On Tue, 5 Nov 2019, Jaroslav Kysela wrote: >>> >>>> I make some internal ucm code cleanups in alsa-lib and added >>>> three >>>> major extensions to allow more complex configurations which we >>>> require for the >>>> SOF kernel driver. >>> >>> looks very good and pragmatic way to tackle some of the issues you >>> hit >>> with current UCM. >>> >>> E.g. the If block would be also sufficient to tackle the recent >>> HDMI codec >>> driver change (with a single UCM file) -- i.e. use existence of the >>> hdac-hdmi driver controls to select which enable-sequences to run. >>> Hmm, I >>> like this better than trying to select a whole different UCM file >>> based on >>> which drivers are used. >>> >>> And same usage pattern can be applied to other mixer control name >>> changes >>> (like you already did for the HDA mic control). >>> >>> That of course leads to the question do we soon need mechanisms to >>> choose between more than two conditions (e.g. if mixer controls >>> have >>> changed multiple times in recent kernels, so covering for this >>> in UCM would need a Switch, If-Else, or similar). But yeah, one can >>> always define another UCM, so keeping-it-simple might be the right >>> choice here. >> >> I already implemented the nested If (so you may use another If in >> the >> True/False blocks). >> >> Also 'String' (equal, substring) and 'RegexMatch' conditions were >> added. >> >> For the substitution, I added ${CardComponents}, too. The driver >> might pass >> another component description strings to the user space for a better >> identification - there is snd_component_add() kernel function for >> this. >> >>>> I added everything to keep the interface backward compatible, >>>> so the >>>> current applications should not observe any different behavior. >>>> The >>>> applications like pulseaudio should use the 'hw:CARD_INDEX' >>>> specifier for the >>>> open call in the future and snd_use_case_parse_ctl_elem_id() >>>> helper for the >>>> element control names. >>> >>> This sounds good as well. Some testing with common versions of >>> e.g. Pulseaudio is probably in order to sanity check how this >>> works. >> >> Yep, I will do more testing. >> >> Do you have any progress with the pulseaudio volume UCM extension? >> Could you >> send me a link to the repository again? Thank you. >> > If you mean the ucm hw volume support: > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/189 > This is my fixes on top of Arun's original patch. > > This is working pretty well for me, for example I have mute leds > working in X1 with this. Unfortunately Pulseaudio community is pretty > loaded with reviews, so no comments yet. > > My problem is also that some distributions are using pulseaudio v11.1 > so backporting is little bit nasty... My personal branch if for some > reason someone want's to test in v11.1: > https://gitlab.freedesktop.org/juimonen/pulseaudio/tree/lenovo_test > (This branch has also couple of backports to support automatic routing > between profiles -> ucm use cases) Thanks, I see the misunderstanding between PlaybackVolume/PlaybackSwitch and PlaybackMixerID . The PlaybackVolume/PlaybackSwitch is for control API (snd_ctl_...) while PlaybackVolumeId is for selem API. The same is for the capture direction. It seems that PA uses the selem API, thus PlaybackVolumeId/CaptureVolumeId should be used (and defined in the ucm configuration files). Also, the zero index for sid worries me, too: SELEM_INIT(sid, e->alsa_name); My machine: $ amixer -D hw:PCH | grep Headphone Simple mixer control 'Headphone',0 Simple mixer control 'Headphone',1 We should also define and handle the dependency for mixer controls (Master -> Headphone) later in UCM and PA should handle this, too. Jaroslav -- Jaroslav Kysela Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel