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@xxxxxxx> 于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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
