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
- 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