input: Phone buttons in USB handsets/phones

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
SPEAKER

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

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.

So I'm a bit stuck at what to do, should I patch yealink to return NUMERIC_xxx codes or switch cm109 to returning KEY_1..KEY_9, KEY_ASTERISK, etc?

Georgi Chorbadzhiyski
http://georgi.unixsol.org/

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.

This should probably be a switch, not a key.

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.

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

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

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