[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A9AE758.2060106@unixsol.org>
Date: Sun, 30 Aug 2009 23:55:52 +0300
From: Georgi Chorbadzhiyski <gf@...xsol.org>
To: Dmitry Torokhov <dtor@...l.ru>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Henk Vergonet <henk.vergonet@...il.com>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
usbb2k-api-dev@...gnu.org
Subject: 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists