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