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

[Takashi Iwai]

On Wed, 28 Nov 2018 05:35:50 +0100,
youling 257 wrote:
> 
> revert "conf/ucm: bytcr-rt5645: Use the generic
> bytcr/PlatformEnableSeq.conf", or add missed <searchdir:ucm-includes>
> for chtrt5645, what do you want?

Avoid top-posting and a bit more context for understanding by human
beings, please :)

In anyway, I see the point, my previous patch was far imperfect.
The second patch will be submitted soon.


thanks,

Takashi

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