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