Hi Mark,
Mark Brown wrote:
On Tue, Jun 23, 2009 at 03:28:54PM +0200, Janusz Krzysztofik wrote:
However, I am not sure if the switch in question matches the alsa jack
model closely enough. I see the switch usage not as simple as turning
handset microphone/speaker on or off. It can be used for other purposes
as well, like accepting a phone call or actually dialing a number that
has been just typed in. Furthermore, it can be used to turn off a
speakerphone function, while, in turn, the related handset
microphone/speaker pair can be turned off not only with this switch, but
with a handsfree button as well, for example.
That can all be accomodated within the ASoC jack framework (I'm assuming
you'll be doing an ASoC rather than generic ALSA driver).
Right, thanks for pointing out the difference.
You get the
input device just the same as you get with gpio-keys so you can do stuff
in user space,
Yes, that was quite simple :). For now, I used SND_JACK_HEADSET report
type. Don't you think that a new type like SND_JACK_PHONE_HOOK or
SND_JACK_PHONE_HANDSET should be defined for the purpose? Even if
HEADSET may not be very different from HANDSET, corresponding
SW_HEADPHONE_INSERT and SW_MICROPHONE_INSERT event names seem have very
little to do with picking up a phone.
the main difference is that you can also arrange for some
of the power management within ASoC to be hooked up with the jack
automatically as well.
With what you're describing above I'd tie the mic and speaker in the
headset to DAPM automatically.
OK, I'll try to follow your advice when I'm ready with a method of
switching my microphones/speakers.
All that extra functionality looks like belonging to userspace rather
then kernel, not like other alsa jack implementations that seem to do
all the job of switching media paths inside the kernel. That is why I am
not sure if the jack model is suitable for the purpose.
The switching in kernel for ASoC should generally be confined to marking
outputs as powered or unpowered - things like marking a headphone jack
as disabled when there's nothing plugged in to it that can be done
unconditionally. Everything else should get punted to user space.
So, if I want to follow the ASoC jack model, my in-kernel hook switch
handler should only power on/off the handset, not touching the
speakerphone at all. The latter should be controlled from userspace.
Please correct me if I am missing something.
Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
