+ Che, Rex and Hui from Canonical
On Tue, 2020-01-07 at 18:33 +0100, Jaroslav Kysela wrote:
Dne 07. 01. 20 v 17:46 Pierre-Louis Bossart napsal(a):
So my last advice was to push the topologies in the normalized .conf format to alsa-topology-conf repository and let the distributions to choose, if they'll put this to their linux-firmware packages or create a standalone package with topologies (which must be installed in the same way as linux-firmware anyway).
I think it's not sustainable to import .conf files, it'd be a better idea to move all M4 files into alsa-topology-conf and provide a script to generate topologies - provided that the results are the *same* as what gets tested by the SOF CI and Intel QA. We should not have multiple options for the topology generation, either we all normalize the intermediate .conf or we don't. Doing otherwise is a sure way of having "works for me" bug reports and confused users.
The .conf files can be very easily compared with the original source.
Basically, I really want to let things to move forward. Everything is better than to have the topology configuration in the big repo with all other things, so I can accept this, too.
I had to probably use my time to work on something different than libatopology, but at least I found several problems and did a lot of cleanups.
I will also assert that topology and UCM files should be released together, the former define stream numbers and control names that are used by the latter.
The packagers should ensure the version sync.
ok, I this should also include the ldc files. I will remove these from linux-firmware.
This would mean that:-
1) linux-firmware would just contain versioned firmware binaries. Soft link would link to latest version unless driver quirk or user (via module param) request earlier version.
2.1) alsa-ucm-conf would contain versioned UCMs
2.2) alsa-ucm-conf would contain versioned topology M4s (local make rule could build and install tplg binaries). Script could copy tagged M4 releases from SOF for convenience.
2.3) alsa-ucm-conf would contain LDC files. Copy script ? Probably better coming from CI as PR as part of a tagged release ?
Question for packagers, how will we version 2.1, 2.2 and 2.3 ? I would assume via git tag ?
If so how do we align alsa-ucm-conf release to kernel and SOF releases ? Do the distros keep manifest of "compatible" ingredient versions that would track this ? I'm guessing the distro maintainer manage this based on the version of kernel in the distro.
If this is acceptable I will push PRs for linux-firmware and alsa-ucm- conf
If we don't release them together we'll be in trouble (e.g. if forthe DMIC name changes).
We are in trouble anyway :-) The new name is not much better (index inside the control name not respecting the rules in control-names.rst - kernel documentation). But I know, someone missed to implement the control indexes in the whole ASoC tree ;-) SOC_SINGLE() etc... I'm talking about snd_kcontrol_new->index.
Oh, that's probably my bad from 15 years ago !
Liam
Jaroslav