Can a phone hook switch follow alsa jack model?

Can a phone hook switch follow alsa jack model?

[Janusz Krzysztofik]

Hi,

I am wondering if it is a good idea to create support for a phone hook 
switch, or a handset pick up switch, like that found on Amstrad E3 
(Delta) videophone, using alsa jack framework.

After my initial attempt to add support for the switch using gpio-keys 
driver, I am no longer sure if it is a good idea to follow the keyboard 
model, that the driver has been designed after, for driving a switch 
that has nothing to do with keyboards and may required a different approach.

OTOH, the switch is closely related to a handset, and handsets can be 
seen as sound devices, can't they? So maybe alsa jack would fit better 
than keyboard?

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.

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.

Thanks,
Janusz

Re: Can a phone hook switch follow alsa jack model?

[Mark Brown]

On Tue, Jun 23, 2009 at 03:28:54PM +0200, Janusz Krzysztofik wrote:

> After my initial attempt to add support for the switch using gpio-keys 
> driver, I am no longer sure if it is a good idea to follow the keyboard 
> model, that the driver has been designed after, for driving a switch 
> that has nothing to do with keyboards and may required a different approach.

That approach was quite common in the past.

> 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).  You get the
input device just the same as you get with gpio-keys so you can do stuff
in user space, 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.

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

Re: Can a phone hook switch follow alsa jack model?

[Janusz Krzysztofik]

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

Re: Can a phone hook switch follow alsa jack model?

[Mark Brown]

On Wed, Jun 24, 2009 at 03:28:11PM +0200, Janusz Krzysztofik wrote:
> Mark Brown 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.

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

Re: [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

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

[Mark Brown]

On Thu, Jun 25, 2009 at 02:48:38PM +0200, Janusz Krzysztofik wrote:

> 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

Something like hook switch would be a more common name - the switch is
closed when the phone is on hook.

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

The _INSERT isn't at all appropriate since there's nothing being
inserted here - the _INSERT names refer to the fact that something is
being plugged in to a jack.

> 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

OTOH a phone going on hook tends to mean something rather different in
UI terms to having something plugged into a jack - it's part of the
normal flow of making a phone call.

Re: Can a phone hook switch follow alsa jack model?

[Janusz Krzysztofik]

On Monday 29 June 2009 16:32:15 Mark Brown wrote:
> On Thu, Jun 25, 2009 at 02:48:38PM +0200, Janusz Krzysztofik wrote:
> > 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
>
> Something like hook switch would be a more common name - the switch is
> closed when the phone is on hook.

I guess so.

> > 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.
>
> The _INSERT isn't at all appropriate since there's nothing being
> inserted here - the _INSERT names refer to the fact that something is
> being plugged in to a jack.

Sure, that's why I tried to replace _INSERT with _PICK_UP, that probably can 
closely refer to what can happen to a handset, while still following the 
general trend of ending switch related event names with action names.

> > 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
>
> OTOH a phone going on hook tends to mean something rather different in
> UI terms to having something plugged into a jack - it's part of the
> normal flow of making a phone call.

That's how I argued once in my message to Jonathan:
> I have choosen a different name to distinguish the switch actual function
> from what we know from telephony world as a switch that connects a phone to
> a line in response to a handset pick up.

Mark,
Thanks for sharing your thoughts. I am not going to waste your time on this 
linguistic debate any more. For now, I keep on using SND_JACK_HEADSET unless 
somebody happens to hit upon a better idea. If there are no other votes, I 
will try to work out a consistent set of symbols using one or another of 
already considered names that would best match current naming schema.

Cheers,
Janusz