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