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

[youling 257]

revert "conf/ucm: bytcr-rt5645: Use the generic
bytcr/PlatformEnableSeq.conf", or add missed <searchdir:ucm-includes>
for chtrt5645, what do you want?

Takashi Iwai <tiwai at suse.de> 于2018年11月28日周三 上午1:12写道：
>
> 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