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.
Regards,
Hans
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
