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?
If buttons are exposed as kcontrols, I suppose "Headphone Button N" would be a fine name.