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