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

[Hans de Goede]

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.

Regards,

Hans