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@xxxxxxxxxx> >>>> >>>> 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 -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
