[alsa-devel] Can a phone hook switch follow alsa jack model?

[Janusz Krzysztofik]

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

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

Mark,
Thanks for now, all that seems clear enough for me.
Janusz