From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH v3 1/2] ALSA: jack: create jack kcontrols for every jack input device Date: Wed, 25 Mar 2015 07:13:06 +0100 Message-ID: References: <1426865953-1606-1-git-send-email-yang.jie@intel.com> <1426865953-1606-2-git-send-email-yang.jie@intel.com> <1427105297.2968.19.camel@tkkaskin-mobl3.ger.corp.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id DFB0B26166B for ; Wed, 25 Mar 2015 07:13:07 +0100 (CET) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: "Jie, Yang" Cc: Liam Girdwood , Tanu Kaskinen , "broonie@kernel.org" , "alsa-devel@alsa-project.org" , "Girdwood, Liam R" List-Id: alsa-devel@alsa-project.org At Wed, 25 Mar 2015 04:11:28 +0000, Jie, Yang wrote: > > > -----Original Message----- > > From: Takashi Iwai [mailto:tiwai@suse.de] > > Sent: Monday, March 23, 2015 7:57 PM > > To: Tanu Kaskinen > > Cc: Jie, Yang; broonie@kernel.org; alsa-devel@alsa-project.org; Girdwood, > > Liam R; Liam Girdwood > > Subject: Re: [PATCH v3 1/2] ALSA: jack: create jack kcontrols for every jack > > input device > > > > At Mon, 23 Mar 2015 12:08:17 +0200, > > Tanu Kaskinen wrote: > > > > > > On Sat, 2015-03-21 at 02:22 +0000, Jie, Yang wrote: > > > > > As you'll find through the whole output, many calls are combined > > > > > with > > > > > SND_JACK_BTN_* bits. And think again how this will result with your > > patch. > > > > > A call like > > > > > > > > > > snd_soc_card_jack_new(card, "Headphone", > > > > > SND_JACK_HEADPHONE | SND_JACK_BTN_0 | > > SND_JACK_BTN_1, ...) > > > > > > > > > > would give three kctls, all "Headphone Jack" with indices 0, 1 and 2. > > > > > How user-space knows what is for what? > > > > [Keyon] yes, this is an issue I was thinking about, we need > > > > discussing and conclusion about that, including comments from user- > > space, here adding Tanu. > > > > Here I am thinking about > > > > 1. do we really need kctls for buttons(SND_JACK_BTN_n)? if no, that > > > > is simplest, we can filter out them at this kctl creating stage. > > > > 2. if yes, then we need an name regenerator here, to generate > > > > understandable (for user-space) kctl names for buttons. > > > > > > >From PulseAudio point of view, you must make sure that "Headphone > > Jack" > > > with index 0 doesn't refer to a button, because the assumption is that > > > "Headphone Jack" at index 0 refers to a jack and not a button (indexes > > > other than 0 are currently ignored). Other than that, PulseAudio > > > doesn't currently care, because there's no support for buttons. > > > > > > When thinking about how to implement button support in PulseAudio, the > > > first question is that are kcontrols a realiable interface for getting > > > button events? What happens when the button is pressed? Does one > > press > > > cause only one on->off or off->on state transition, or is the state "on" > > > only for the duration of the press? If the former, then kcontrols > > > should be fine, but if the latter, is it guaranteed that the > > > application sees the event? If the button press is a short one, > > > causing a quick > > > off->on->off transition, is it possible that the application gets a > > > notification of a mixer change, but when the application then inspects > > > the mixer state, the button state is already "off", so the application > > > doesn't get enough information about what happened? > > > > It's a good point. The notification via kctl can't follow the complete state > > changes since it's nothing but a notification telling "something changed". So, > > events like buttons that need the complete state change history, the current > > implementation isn't appropriate. > > For things like jacks, we usually care only about the final state, and the state > > change is much less frequent, so kctl notification works well. > [Keyon] Agree that we don't need create kctl for button(just leave it to input > event notification/handler), then I can update patch to filter out them at kctl > creating stage, which may make life easier IMO. :) > > BTW, Takashi, according to what Tanu mentioned, kctls indexes other than 0 > are currently ignored by PA, so creating and exporting kctls with non-zero > indices for the same name in HD-Audio Jack before, seems no use for upper > layer? No "big" use. Who knows. But I don't mind to convert the usage of index number in hda_jack.c to a unique string instead so that the name can be used for both input and kctl jacks. Takashi