Dne 03. 09. 19 v 9:47 Hans de Goede napsal(a):
Hi,
On 02-09-19 17:32, Takashi Iwai wrote:
On Mon, 02 Sep 2019 10:31:30 +0200, Hans de Goede wrote:
Hi Takashi,
On 02-09-19 09:07, Takashi Iwai wrote:
On Sat, 31 Aug 2019 16:58:41 +0200, Hans de Goede wrote:
Add an UCM profile for Intel boards with a RT5672 codec.
Re-use the existing platform enable and disable sequences for BYT/CHT SST support and add a codecs/rt5672 dir with codec specific enable / disable sequences for the various inputs and outputs.
This is partly based on earlier work done here: https://github.com/plbossart/UCM/tree/master/cht-bsw-rt5672
Signed-off-by: Hans de Goede hdegoede@redhat.com
We've recently set up a new alsa-ucm-conf repo for keeping UCM profiles outside alsa-lib repo. The new repo has a different license (BSD3-Clause) for easily adapting to OSes with license restriction.
I guess we should put the stuff there from now on, as much as possible? The handling of UCM profile is currently pending, and we need to decide the general policy, as well as how to transfer the existing profiles to the new repo...
I think it is good that we now have a separate repo and I'm fine with re-licensing all my UCM profile work under a BSD3-Clause license.
But I believe that until we have actually figured out how this is all going to work and we are actually doing releases from the new alsa-ucm-conf repo, we should keep adding new profiles to alsa-lib for now, because these profiles are necessary for things to work OOTB for our end users.
Well, putting to both repos isn't a good idea from the packaging POV, either. If we're going to release the alsa-ucm-conf sooner or later together with the next alsa-lib release, we can put into the new repo from the beginning.
Well, we want to move some of the other UCM profiles over too, right? (I guess eventually we want to move all of them over)
So we are going to have this duplicate profile problem anyways.
I was thinking of adding a --without-duplicate-ucm-profiles option to alsa-lib's ./configure which when used disables installation of UCM profiles which have a copy in the new alsa-ucm-conf.
This will give use a transition period, where distros can choose to either use alsa-lib with --without-duplicate-ucm-profiles + the new alsa-ucm-conf, or just use alsa-lib as they have before. Note the idea is for this to be temporary, eventually the profiles which are "disabled" by --without-duplicate-ucm-profiles can be dropped and the option removed.
OTOH if you plan to make sure that the next alsa-lib release is done in sync with the first alsa-ucm-conf release and you plan to move the UCM profiles which can be moved (licensing) before that, giving us a clean break, then that is fine too.
Yes, that sounds good. I will also try to send e-mail to all authors for the permission to change the licence to BSD3-Clause license. Perhaps, we can get all agreements before the next alsa-lib is released, so all UCM profiles will be moved to the new repository and the configuration option --without-duplicate-ucm-profiles will not be required.
Jaroslav