public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
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

  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