From: David Henningsson <david.henningsson@canonical.com>
To: "Jie, Yang" <yang.jie@intel.com>, Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"Girdwood, Liam R" <liam.r.girdwood@intel.com>
Subject: Re: [PATCH v4 0/5] ALSA: jack: Refactoring for jack kctls
Date: Wed, 08 Apr 2015 10:27:35 +0200 [thread overview]
Message-ID: <5524E677.2020803@canonical.com> (raw)
In-Reply-To: <E7B1D079BA13FB44A978CC8F69C7D6A90550618B@shsmsx102.ccr.corp.intel.com>
On 2015-04-08 09:59, Jie, Yang wrote:
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Wednesday, April 08, 2015 3:21 PM
>> To: Takashi Iwai; Jie, Yang
>> Cc: alsa-devel@alsa-project.org; broonie@kernel.org; Girdwood, Liam R
>> Subject: Re: [alsa-devel] [PATCH v4 0/5] ALSA: jack: Refactoring for jack kctls
>>
>>
>>
>> On 2015-04-07 18:06, Takashi Iwai wrote:
>>> This would work, yes. But, I have some uneasy feeling, something not
>>> well digested...
>>>
>>> Ideally, we want a single API for representing both input and kctl
>>> jacks.
>>
>> Maybe this is somewhat my fault for steering Yang in that direction. But the
>> requirements are somewhat different.
>>
>> HDA has the phantom jacks, and the exact naming for each kctl requirements.
>> ASoC has the combination/button requirements, i e one jack can represent
>> more than one kctl.
>>
>> The phantom jack requirement means that the snd_kctl_jack_new API
>> cannot be removed straight away; we could move it to be internal to HDA
>> (it's not much code anyway), but I don't see a need for that.
>>
>> But the HDA code can be moved around to look like this:
>>
>> if (phantom_jack) {
>> snd_kctl_jack_new();
>
> Let me add line here to clarify:
> + snd_hda_ctl_add();
>
>> }
>> else {
>> snd_jack_new();
>> snd_jack_add_new_kctls();
>
> I thought of this at the beginning, as you talk below, it looks more like what
> we did for ASoC case.
>
> What I concern here is that it may make input jack kctl looks like a little
> different with before(I am not sure, maybe you guys are more clearly about
> what will occurs without calling snd_ctl_add()-->snd_array_new()...)?
I'm not sure I understand this question. Maybe the answers below help
answering it?
>> }
>>
>> Now the HDA looks more like the ASoC variant. Yang, what do you think
>> about that? That would make the API simpler, wouldn't it?
>
> Here repeat what I stated in another reply:
>
> For jack creating, we use the same API -- snd_jack_new();
>
> For kctl creating, yes, we use different APIs:
> snd_jack_kctl_new() for input jacks(HDA),
> snd_jack_add_kctls() for kctl jacks(ASoC).
>
> There are 2 reasons that I made them different:
> 1. a. for HDA phantom jack, in the old/exist logic, __snd_hda_jack_add_kctl()
> will also call snd_kctl_jack_new() and snd_hda_ctl_add(), it will create kctls
> and add them to card(also assigning some arrays, they are different with calling
> snd_ctl_add() only, which is what we will do for ASoC kctl adding);
Actually, now that I look at snd_hda_ctl_add, I don't know why we need
to call it for HDA jacks. There does not seem to be anything relevant
for HDA jacks there. I think we can just call snd_ctl_add for HDA jacks too.
With your refactoring, all we need to remember is to remove the jacks (i
e both the input device and the kctls) in both snd_hda_codec_reset and
snd_hda_codec_free, and I suspect this is already taken care of?
> b. for HDA input/phantom jack, all of those occurs before calling
> snd_jack_new().
My point is that it would be possible to move the HDA code around so
that snd_jack_new is called first. And with Takashi's suggestion of a
"create_input_dev" flag, it would be called for both real and phantom jacks.
> So, we have to split jack new and kctl new functions here, because for HDA
> phantom/input jack and ASoC kctl jack, they are quite different here.
>
> 2. we may need generate kctl name for ASoC kctls(snd_jack_kctl_name_gen(),
> removing suffix " Jack" as you proposed before, or everything needed after);
> but for HDA input jack kctls, the naming has been finished before calling
> __snd_hda_jack_add_kctl(), we should not change them anymore.
snd_jack_kctl_name_gen seems only to remove a " Jack" suffix. I think we
can safely call it for both ASoC and HDA jacks. If a HDA jack ends up
being labelled something with " Jack Jack", it's a bug anyway.
(Side note: but you might want to fix snd_jack_kctl_name_gen to make
strange names like "My Jacket Computer" not be cropped to "My Jacket Com")
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
next prev parent reply other threads:[~2015-04-08 8:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-03 12:07 [PATCH v4 0/5] ALSA: jack: Refactoring for jack kctls Jie Yang
2015-04-03 12:07 ` [PATCH v4 1/5] ALSA: jack: create jack kcontrols for every jack input Jie Yang
2015-04-03 12:07 ` [PATCH v4 2/5] ALSA: jack: add a parameter to pass kctl for snd_jack_new Jie Yang
2015-04-03 12:07 ` [PATCH v4 3/5] ALSA: hda - Update to use the new jack kctls method Jie Yang
2015-04-03 12:07 ` [PATCH v4 4/5] ASoC: jack: create kctls according to jack pins info Jie Yang
2015-04-03 12:07 ` [PATCH v4 5/5] ALSA: jack: remove export snd_kctl_jack_new() Jie Yang
2015-04-06 16:11 ` [PATCH v4 0/5] ALSA: jack: Refactoring for jack kctls Mark Brown
2015-04-07 16:06 ` Takashi Iwai
2015-04-08 2:53 ` Jie, Yang
2015-04-08 4:39 ` Raymond Yau
2015-04-08 7:20 ` David Henningsson
2015-04-08 7:34 ` Takashi Iwai
2015-04-08 7:49 ` David Henningsson
2015-04-08 7:59 ` Jie, Yang
2015-04-08 8:27 ` David Henningsson [this message]
2015-04-08 9:18 ` Jie, Yang
2015-04-08 9:22 ` Takashi Iwai
2015-04-08 14:14 ` Jie, Yang
2015-04-08 14:29 ` Takashi Iwai
2015-04-08 18:47 ` David Henningsson
2015-04-08 18:55 ` Takashi Iwai
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=5524E677.2020803@canonical.com \
--to=david.henningsson@canonical.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=liam.r.girdwood@intel.com \
--cc=tiwai@suse.de \
--cc=yang.jie@intel.com \
/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