diff mbox

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

Message ID 1502155666-31366-1-git-send-email-leo.wen@rock-chips.com
State Deferred
Delegated to: Marek Vasut
Headers show

Commit Message

Leo Wen Aug. 8, 2017, 1:27 a.m. UTC
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.

Signed-off-by: Leo Wen <leo.wen@rock-chips.com>
---
 common/usb_kbd.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Philipp Tomsich Aug. 9, 2017, 10:33 a.m. UTC | #1
> On 08 Aug 2017, at 03:27, Leo Wen <leo.wen@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@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
> 
>
Simon Glass Aug. 13, 2017, 9:36 p.m. UTC | #2
Hi,

On 9 August 2017 at 04:33, Dr. Philipp Tomsich
<philipp.tomsich@theobroma-systems.com> wrote:
>
>> On 08 Aug 2017, at 03:27, Leo Wen <leo.wen@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)?

There is no relation unfortunately. The usb protocol uses a different
encoding I believe.

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

I think escape codes should be used, but I am not an expert on this.

>
> 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@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
>>
>>

Regards,
Simon
diff mbox

Patch

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
+};
 
 /*
  * 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))