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
