linux-kernel - Re: input: Phone buttons in USB handsets/phones

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20090901021024.EC446526EA5@mailhub.coreip.homeip.net>
Date:	Mon, 31 Aug 2009 18:37:46 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Georgi Chorbadzhiyski <gf@...xsol.org>
Cc:	Henk Vergonet <henk.vergonet@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	usbb2k-api-dev@...gnu.org
Subject: Re: 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
--
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/