Re: [PATCH v3 1/2] ALSA: jack: create jack kcontrols for every jack input device

[Takashi Iwai <tiwai@suse.de>]

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