[U-Boot] [PATCH] common:usb_kbd:Add key values of F1~F12

[Dr. Philipp Tomsich]

> On 08 Aug 2017, at 03:27, Leo Wen <leo.wen at rock-chips.com> wrote:
> 
> When you press the F1~F12 button from the USB keyboard, the reference Fn
> key table(usb_kbd_fn_key[]),the key value(0xf0~0xfb) will be returned,
> and you can use it to do more things.

How does doing this code (in usb_kbd.c) relate to the translation matrices
in drivers/input/input.c (which maps from a scancode—i.e. ’typical AT-101
position’ column in the USB HUT document—to the internal character
value in U-Boot)?

And should we even expose the function keys via getc() instead of generating
escape sequences? The key values 0xf0 through 0xfb are usually not associated
with F1 through F12.

Note that with drivers/input/input.c, I would expect escapes to be generated
for KEY_F1 (\033OP) through KEY_F12 (\033[24~)… which would need to
be added to the kbd_to_ansi364 table.

> Signed-off-by: Leo Wen <leo.wen at rock-chips.com>
> ---
> common/usb_kbd.c | 7 +++++++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/common/usb_kbd.c b/common/usb_kbd.c
> index d2d29cc..7c96c78 100644
> --- a/common/usb_kbd.c
> +++ b/common/usb_kbd.c
> @@ -73,6 +73,10 @@ static const unsigned char usb_kbd_num_keypad[] = {
> 	'1', '2', '3', '4', '5', '6', '7', '8', '9', '0',
> 	'.', 0, 0, 0, '='
> };
> +static const unsigned char usb_kbd_fn_key[] = {
> +	0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5,
> +	0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb
> +};

Why did you choose these values to encode F1 through F12?
Is there some precedent for using these character codes for these keys?

> 
> /*
>  * map arrow keys to ^F/^B ^N/^P, can't really use the proper
> @@ -206,6 +210,9 @@ static int usb_kbd_translate(struct usb_kbd_pdata *data, unsigned char scancode,
> 		else
> 			keycode = usb_kbd_numkey[scancode - 0x1e];
> 	}
> +	/* Fn keys pressed */
> +	if ((scancode >= 0x3a) && (scancode <= 0x45))
> +		keycode = usb_kbd_fn_key[scancode - 0x3a];
> 
> 	/* Arrow keys */
> 	if ((scancode >= 0x4f) && (scancode <= 0x52))
> -- 
> 2.7.4
> 
>