From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
To: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>,
Cezary Rojewski <cezary.rojewski@intel.com>,
Mark Brown <broonie@kernel.org>,
ALSA development <alsa-devel@alsa-project.org>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>
Subject: Re: [alsa-devel] UCM extensions
Date: Thu, 7 Nov 2019 13:54:10 +0200 (EET) [thread overview]
Message-ID: <alpine.DEB.2.21.1911071326410.16459@zeliteleevi> (raw)
In-Reply-To: <c53c36a7-bb55-abca-0e4f-9574d8fe3660@perex.cz>
Hi,
On Thu, 7 Nov 2019, Jaroslav Kysela wrote:
> Dne 07. 11. 19 v 11:18 Cezary Rojewski napsal(a):
> > On 2019-11-05 20:36, Jaroslav Kysela wrote:
> > However, I have some concerns here. First, could you elaborate on "we
> > require for the SOF kernel driver"?
>
> Please, look here:
>
> https://github.com/alsa-project/alsa-ucm-conf/commit/a8253465aef2df494ccd5b1103412b0318be582e#diff-a2ba34aee1a55c2fd664d78624477173L37
>
> The HDA driver sometimes manages different JackControl names depending on the
> used codec and it would be the real maintenance mess to use the DMI info (long
> card name) for all possible configurations.
>
> Also, if you look to the current configs, many duplications can be removed
> with the If evaluations.
yes, I agree with Jaroslav here. There's definitely the risk of making
UCM files too complex, but pragmatically, we really need something between
the current boolean choice between a generic UCM picked by card
shortname and per-product tailored UCM'es picked up by card longname.
There's some variation in HDA codec controls that is more
convenient to hide in if-else logic in the generic UCM. Same goes
for addition of controls to the kernel. Without conditional logic, using
a newer UCM file with an older kernel simply breaks -- even if the change
is incremental only.
There was a discussion in the summer on the list about adding versions in
kernel and using that to help pick the right UCM profile. This isn't an
easy path either -- there are many components contributing to the
overall card interface on kernel side, and you still need to pick (or
compile at runtime) a single UCM file. It would seem with Jaroslav's
current proposal, you could cover majority types of minor variations
and thus significantly limit the number of UCM files that need to be
maintained.
Br, Kai
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
prev parent reply other threads:[~2019-11-07 11:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 19:36 [alsa-devel] UCM extensions Jaroslav Kysela
2019-11-05 19:52 ` Pierre-Louis Bossart
2019-11-05 20:19 ` Jaroslav Kysela
2019-11-05 20:27 ` Pierre-Louis Bossart
2019-11-06 11:50 ` Kai Vehmanen
2019-11-06 13:10 ` Jaroslav Kysela
2019-11-06 13:51 ` Jaska Uimonen
2019-11-06 17:04 ` Jaroslav Kysela
2019-11-07 6:48 ` Takashi Iwai
2019-11-07 8:33 ` Jaroslav Kysela
2019-11-07 9:23 ` Takashi Iwai
2019-11-07 11:08 ` Jaroslav Kysela
2019-11-07 11:16 ` Takashi Iwai
2019-11-07 13:14 ` Jaroslav Kysela
2019-11-07 10:18 ` Cezary Rojewski
2019-11-07 11:01 ` Jaroslav Kysela
2019-11-07 11:54 ` Kai Vehmanen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1911071326410.16459@zeliteleevi \
--to=kai.vehmanen@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.