[alsa-devel] [PATCH v2 01/13] conf/ucm: bytcr-rt5645: Use the generic bytcr/PlatformEnableSeq.conf

[Takashi Iwai]

On Tue, 27 Nov 2018 18:08:30 +0100,
Pierre-Louis Bossart wrote:
> 
> 
> >> - what is the license for those UCM files? I keep getting questions
> >> and I don't have the answer. It'd be odd to have then inherit the LGPL
> >> license from alsa-lib, it's expected that people will have to do minor
> >> modifications left and right and handle a number of derivatives,
> >> e.g. because the perceived volume is too low due to some
> >> mechanics/acoustics issue and requiring them to share is a bit
> >> cumbersome.
> > Unless explicitly specified, it should inherit from the whole alsa-lib
> > license, i.e. LGPL.  But I guess we have no problem for re-licensing
> > (or dual-license) with a more relaxed one for UCM profiles, once when
> > they are split to an individual repo.
> >
> > Since the whole projects were moved to github, we can do it easily, I
> > suppose.
> 
> I think we should have UCM and topology files in the same repo since
> they are related (control names, etc).

OK, makes sense.

> BTW that's also one improvement that I forgot about. alsa-lib
> currently bails when it cannot find a control in an UCM file, and
> that's painful when control names change over time. I have e.g. older
> UCM profiles for Chromebooks that aren't compatible any longer with
> the upstream kernel for HDMI paths, but work fine with analog
> paths. It'd be really nice to downgrade the error to a warning.

Yeah, I've hit this a few times as well :)
It'd be helpful to fallback or allow optional controls.

> >
> >> - how are we going to handle the changes for SOF, we added an "sof-"
> >> prefix to make it explicit that the platform/DSP driver side is
> >> different, but having a different board name will interfere with
> >> search and includes.
> > Sorry, it's not clear about the question.  You need to use a different
> > UCM profile when the device is bound with SOF, right?
> 
> It's only different for the DSP parts, the codec settings are
> completely identical so I was hoping to avoid duplication of all the
> profiles and use some sort of run-time rule to only include the
> changed DSP settings. I don't have a turn-key solution to suggest,
> just a desire to avoid more maintenance work just because of a prefix
> added.

Some string manipulations should be available in the alsa-lib config
syntax, so a thing like a control name might be set dynamically
(hopefully).

But my coverage and memory in that area are a bit vague, so let me see
again once when more concrete pictures show up.


thanks,

Takashi