[alsa-devel] [PATCH 1/2] conf/ucm: Add UCM profile for cht-bsw-rt5672 boards

[Jaroslav Kysela]

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 at 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

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.