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

[Takashi Iwai]

On Mon, 26 Nov 2018 18:20:41 +0100,
Pierre-Louis Bossart wrote:
> 
> 
> On 11/26/18 9:28 AM, Jaroslav Kysela wrote:
> > Dne 26.11.2018 v 15:18 Takashi Iwai napsal(a):
> >> On Mon, 26 Nov 2018 14:40:48 +0100,
> >> Hans de Goede wrote:
> >>>> some of the recently added UCM profiles are the files to be included
> >>>> by others, and they are not card targets.  Unfortunately alsaucm
> >>>> doesn't know about it, and it aborts with error, e.g.
> >>>>
> >>>> ====
> >>>> % alsaucm
> >>>> ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/bytcr/bytcr.conf
> >>>> ALSA lib parser.c:1427:(load_master_config) error: could not parse configuration for card bytcr
> >>>> alsaucm: unable to obtain card list: No such file or directory
> >>>> ====
> >>>>
> >>>> The similar error is found in nau8824, rt5640 and rt5651.  After
> >>>> putting a placeholder card config file (e.g. bytcr.conf), the error is
> >>>> gone.  But certainly we don't want to allow user to choose this as the
> >>>> proper card.
> >>>>
> >>>> So, I guess we need to put some flag to each such directory indicating
> >>>> that it's no card config.  For example, putting
> >>>> /usr/share/alsa/ucm/bytcr/.nocard file or such...
> >>>>
> >>>> Not sure whether it's wise to have a file starting with dot, though.
> >>>> Maybe clearer to be "nocard" or any other visible one?
> >>> All the HiFi.conf files using the "include" snippets I added to avoid
> >>> copy and pasting a lot, already need to have this at the top for
> >>> this to work:
> >>>
> >>> <searchdir:ucm>
> >>>
> >>> So it might be best to move all the dirs holding include files rather
> >>> then proper card configs from /usr/share/alsa/ucm to
> >>> /usr/share/alsa/ucm-includes and then change the searchdir part of
> >>> the configs using these to:
> >>>
> >>> <searchdir:ucm-includes>
> >> This sounds like a good solution, indeed.
> >> Care to submit a fix patch?  I'll apply it unless anyone objects.
> > Yep, it looks like a good idea.
> 
> Makes sense.

OK, I cooked up the patch now.  Will submit soon later.


> We may also want to change the error message when the DMI-based
> configuration is not found, e.g.
> 
> ALSA lib utils.c:67:(uc_mgr_config_load) could not open configuration
> file
> /usr/share/alsa/ucm/ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA/ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA.conf 
> 
> 
> ALSA lib parser.c:1427:(load_master_config) error: could not parse
> configuration for card ASUSTeKCOMPUTERINC.-X205TA-1.0-X205TA
> 
> This is reported as an error even if there is a fallback. I remember
> losing a couple of hours trying to figure out what was happening when
> in reality there was no issue.

A good point, it should be suppressed.

> I have two other points I need to sort out
> 
> - 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.

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


thanks,

Takashi