[alsa-devel] [PATCH alsa-lib 1/4] ucm: Fix opening of master-configs by the card's longname

Takashi Iwai tiwai at suse.de
Mon Nov 25 11:12:38 CET 2019


On Tue, 19 Nov 2019 16:32:07 +0100,
Hans de Goede wrote:
> 
> Hi,
> 
> On 19-11-2019 14:21, Jaroslav Kysela wrote:
> > Dne 19. 11. 19 v 13:40 Hans de Goede napsal(a):
> >> Hi,
> >>
> >> On 19-11-2019 13:23, Jaroslav Kysela wrote:
> >>> Dne 19. 11. 19 v 11:48 Hans de Goede napsal(a):
> >>>> Prior to commit aba2260ae7b5 ("ucm: switch to ucm2 directory and v2 format,
> >>>> keep backward compatibility").
> >>>>
> >>>> The filename build in parse_verb_file() was build like this:
> >>>> <prefix>/<uc_mgr->conf_file_name>/<file>
> >>>>
> >>>> Where uc_mgr->conf_file_name would contain either the card_name or the
> >>>> card's longname depending on the detection of a longname based config in
> >>>> uc_mgr_import_master_config().
> >>>>
> >>>> While the filename used in load_master_config() was build like this:
> >>>> <prefix>/<card_name>/<card_name>.conf
> >>>>
> >>>> And uc_mgr_import_master_config() first calls load_master_config()
> >>>> with the card's longname and if that succeeds it overwrites
> >>>> uc_mgr->conf_file_name with the longname so that the subsequent uses
> >>>> of uc_mgr->conf_file_name in parse_verb_file() correctly use the longname.
> >>>>
> >>>> But the new configuration_filename() helper added in commit aba2260ae7b5
> >>>> _always_ builds the filename like this:
> >>>> <prefix>/<uc_mgr->conf_file_name>/<file><suffix>
> >>>>
> >>>> This breaks the loading of the master-config by its longname, as when
> >>>> the longname is tried uc_mgr->conf_file_name still contains the card_name.
> >>>
> >>> Hi Hans,
> >>>
> >>> This new behaviour was intended for ucm2. I applied all four your patches, and added 10a63e093c4a98acfa9bcdfdd06938bcd874b008 on top which should keep the
> >>> new behaviour for v2 configs.
> >>
> >> Ah I see.
> >>
> >> There is a bug in the commit you added on top though,
> >> when load_master_config() gets called with longname == 1
> >> and ALSA_CONFIG_UCM2_VAR is not set and ALSA_CONFIG_UCM_VAR
> >> is set, then the if condition in the block is false, so it never executes:
> >>
> >> +               if (getenv(ALSA_CONFIG_UCM2_VAR) || !getenv(ALSA_CONFIG_UCM_VAR)) {
> >> +                       uc_mgr->conf_format = 2;
> >> +                       configuration_filename(uc_mgr, filename, sizeof(filename),
> >> +                                              uc_mgr->conf_file_name, card_name, ".conf");
> >> +               }
> >>
> >> Causing the next block to also not execute:
> >>
> >> +               if (uc_mgr->conf_format >= 2 && access(filename, R_OK) != 0) {
> >> +                       /* try the old ucm directory */
> >> +                       uc_mgr->conf_format = 1;
> >> +                       configuration_filename(uc_mgr, filename, sizeof(filename),
> >> +                                              card_name, card_name, ".conf");
> >> +                       if (access(filename, R_OK) != 0)
> >> +                               return -ENOENT;
> >> +               }
> >>
> >> Causing load_master_config() to continue with an uninitialized filename.
> >>
> >> I think you wanted the following condition for the second block:
> >>
> >>                   if (uc_mgr->conf_format == 0 || access(filename, R_OK) != 0) {
> >>
> >> Also don't you want the same behavor wrt forcing the conf_format based
> >> on env. when trying the shortname ?
> >>
> >> I think you can move the entire block under if (longname) to be unconditional,
> >> since conf_file_name == card_name for the shortname case using the longname
> >> path in the shortname case too is fine. Then you always call configuration_filename
> >> with conf_format set and all the handling for conf_format not being set (and
> >> for overriding it) can be dropped from configuration_filename() then.
> >
> > Thanks again, fixed in 1d848ab739f0d207098627d2ba66421b3ec75eeb .
> >
> >>
> >>> It's time to create the 1.2.1.1 bugfix alsa-lib release, I guess.
> >>
> >> Yes that is a good idea (once the above is resolved).
> >
> > The tar ball is in ftp://ftp.alsa-project.org/pub/testing .
> 
> Thanks, I've given this a quick test spin, the 1.2.1.1 tarbal looks good to me.

Jaroslav, when will this tarball released officially?


thanks,

Takashi


More information about the Alsa-devel mailing list