lkml.org 
[lkml]   [2009]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: input: Phone buttons in USB handsets/phones
On Sun, Aug 30, 2009 at 11:55:52PM +0300, Georgi Chorbadzhiyski wrote:
> Hi guys, I'm patching yealink.c to support p4k phone and
> I'm wondering what to do about the extra buttons that are
> found the phone [1] but are not defined as KEY_xxxxxx in
> input.h?
>
> For example the phone that I'm working with have these
> buttons that do not have matching definitions in input.h:
>
> FLASH
> REDIAL

There is nothing thst stops us from adding more KEY_* definitons to
input.h as long as it is shown that will be used by drivers and
applications.

> SPEAKER

This should probably be a switch, not a key.


>
> for testing purposes I mapped them to f, r and s
> but that's probably not what should be done.
>
> So what to do about them?
>
> [1]: http://www.von-phone.com/prodimages/P4K-functions.jpg
>
> Right now mapping looks like this:
>
> +
> +/*
> + * USB-P4K button layout:
> + *
> + * IN up OUT
> + * VOL+ DEL
> + * VOL- down DIAL
> + *
> + * 1 2 3
> + * 4 5 6
> + * 7 8 9
> + * * 0 #
> + *
> + * HELP (S) SEND
> + * FLASH REDIAL
> + *
> + * The "up" and "down" keys, are one big key
> + * The (S) is one big green key with speaker picture on it
> + */
> +static int map_p4k_to_key(int scancode)
> +{
> + switch(scancode) { /* phone key: */
> + case 0x34: return KEY_LEFT; /* IN */
> + case 0x32: return KEY_UP; /* up */
> + case 0x10: return KEY_RIGHT; /* OUT */
> + case 0x30: return KEY_DOWN; /* down */
> + case 0x31: return KEY_VOLUMEUP; /* VOL+ */
> + case 0x40: return KEY_VOLUMEDOWN; /* VOL- */
> + case 0x33: return KEY_BACKSPACE; /* DEL */
> + case 0x00: return KEY_ENTER; /* DIAL */
> + case 0x21: return KEY_1; /* 1 */
> + case 0x11: return KEY_2; /* 2 */
> + case 0x01: return KEY_3; /* 3 */
> + case 0x22: return KEY_4; /* 4 */
> + case 0x12: return KEY_5; /* 5 */
> + case 0x02: return KEY_6; /* 6 */
> + case 0x23: return KEY_7; /* 7 */
> + case 0x13: return KEY_8; /* 8 */
> + case 0x03: return KEY_9; /* 9 */
> + case 0x24: return KEY_KPASTERISK; /* * */
> + case 0x14: return KEY_0; /* 0 */
> + case 0x04: return KEY_LEFTSHIFT |
> + KEY_3 << 8; /* # */
> + case 0x05: return KEY_HELP; /* HELP */
> + case 0x15: return KEY_F; /* FLASH */
> + case 0x20: return KEY_S; /* SPEAKER */
> + case 0x25: return KEY_SEND; /* SEND */
> + case 0x44: return KEY_R; /* REDIAL */
> + }
> + return -EINVAL;
> +}
>
> A related question - cm109 driver uses KEY_NUMERIC_xxx constants
> but since yealink is an older driver (merged in 2.6.14-rc1) it
> returns KEY_0..KEY_9, KPASTERISK and a hack to return #.
>
> Is it a good idea to make yealink return KEY_NUMERIC_xxxx codes
> since they are specially designed for numeric keypads (phones).
>

It would be great but I am concerned about breaking existing users;
I will gladly accept the patch that would add module option causing
yealink to start using KEY_NUMERIC_* and also allowing changing keymap
from userspace.

> On one hand this will unify somehow codes returned by cm109
> (supports at least 5 different usb phone models) and yealink
> (lots of nice usb phones) but on the other hand support for
> KEY_NUMERIC_xxx should be added to every application that
> right now is working fine with yealink driver (but not cm109).
> Right now returning normal 1,2,3,etc makes testing the driver
> a lot easier. Just plug the phone and enter some numbers.
> In this case KEY_NUMERIC_xxxx codes are PITA.
>

Just fix your keymaps. It should be done just once.

> So I'm a bit stuck at what to do, should I patch yealink
> to return NUMERIC_xxx codes

Patch yealink (but keep compatibility by default), advise application
users to switch to new keymap style.

> or switch cm109 to returning
> KEY_1..KEY_9, KEY_ASTERISK, etc?

No, because then it will not work for French users (or anyone whose
default keymap has digits in _upper_ register). That was the reson for
introducing KEY_NUMERIC_* (KEY_1 & are are affected by keymap and shift
state, KEY_KP1 & co. are affected by numlock state).

--
Dmitry


\
 
 \ /
  Last update: 2009-09-01 03:41    [W:0.030 / U:43.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site