[alsa-devel] Can a phone hook switch follow alsa jack model?
jkrzyszt at tis.icnet.pl
Thu Jun 25 14:48:38 CEST 2009
On 2009-06-25 13:05, Mark Brown wrote:
> On Wed, Jun 24, 2009 at 03:28:11PM +0200, Janusz Krzysztofik wrote:
>> 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.
> Possibly, TBH I had thought I'd seen something for off-hook when I
> looked at this originally but I can't seem to spot it now.
As I am not native English, please somebody help me to choose best
names, both SW_... event name and SND_JACK_... jack type.
During my previous, gpio-keys based attempt, I submitted a patch that
added new SW_HANDSET_PICK_UP event definition to include/linux/input.h.
Even if not accepted because of no acompanying code that would make use
of it, there were no other comments, especially on the name I have
choosen. However, there were another name proposed by ams-delta board
maintainer, Jonathan McDowell - SW_PHONE_HOOK. Even if my wording may
better match those already existing ..._INSERT names, I am not sure
which one should I use.
Please also note that SND_JACK_HEADSET, that I temporarily use for now,
is an alias for SND_JACK_HEADPHONE | SND_JACK_MICROPHONE. Those two can
be seen as matching what a handset actually is. On headset jack
insert/remove, two distinct reports/events are generated, one for a
microphone, and one for a headphone. Should this schema be used with a
handset? Even if it were possible to turn any of handset microphone or
headphone individually, would it make any sense?
Sorry for bothering you with all this stuff, but I'd like the changes to
existing code I am going to propose, if any, be as much reusable as
>> 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.
> That's my initial guess - I've not looked at your particular hardware
> so it may not end up being the best way of dealing with your system but
> from what you said it was the approach that sprang to mind.
Thanks for now, all that seems clear enough for me.
More information about the Alsa-devel