From: Hans de Goede <hdegoede@redhat.com>
To: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>,
alsa-devel@alsa-project.org,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH alsa-lib 1/4] ucm: Fix opening of master-configs by the card's longname
Date: Tue, 19 Nov 2019 16:32:07 +0100 [thread overview]
Message-ID: <13c01b25-809f-cbc7-8e5f-db3ac8e99172@redhat.com> (raw)
In-Reply-To: <8d5a2fa8-9294-bee4-1cef-24bcf2c325a9@perex.cz>
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.
Regards,
Hans
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2019-11-19 15:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-19 10:48 [alsa-devel] [PATCH alsa-lib 1/4] ucm: Fix opening of master-configs by the card's longname Hans de Goede
2019-11-19 10:48 ` [alsa-devel] [PATCH alsa-lib 2/4] ucm: Fix fallback to card_name (shortname) config for ucm1 profiles Hans de Goede
2019-11-19 10:48 ` [alsa-devel] [PATCH alsa-lib 3/4] ucm: Only look in ucm[1] or ucm2 dir once we've found a config file in one Hans de Goede
2019-11-19 10:48 ` [alsa-devel] [PATCH alsa-lib 4/4] ucm: parser: Fix snprintf usage Hans de Goede
2019-11-19 12:23 ` [alsa-devel] [PATCH alsa-lib 1/4] ucm: Fix opening of master-configs by the card's longname Jaroslav Kysela
2019-11-19 12:40 ` Hans de Goede
2019-11-19 13:21 ` Jaroslav Kysela
2019-11-19 15:32 ` Hans de Goede [this message]
2019-11-25 10:12 ` Takashi Iwai
2019-11-25 10:51 ` Jaroslav Kysela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13c01b25-809f-cbc7-8e5f-db3ac8e99172@redhat.com \
--to=hdegoede@redhat.com \
--cc=alsa-devel@alsa-project.org \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).