All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.