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

[Jie, Yang]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Monday, March 23, 2015 7:57 PM
> To: Tanu Kaskinen
> Cc: Jie, Yang; broonie at kernel.org; alsa-devel at 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?

> 
> 
> Takashi