| Message ID | 20190323013002.27117-8-andre.przywara@arm.com |
|---|---|
| State | Accepted |
| Commit | c99ffd72ab1e94d9ffcf61d09f25b75f6a8baaaa |
| Delegated to: | Anatolij Gustschin |
| Headers | show |
| Series | video/console: Fix various DM_VIDEO console issues | expand |
On Fri, 22 Mar 2019 at 19:32, Andre Przywara <andre.przywara@arm.com> wrote: > > So far arrows key pressed on an USB keyboard got translated to some > low ASCII control sequences (Ctrl+N, Ctrl+P). Some programs understand > these codes, but the standard for those keys is to use ANSI control Which standard? > sequences for cursor movement (ESC [ A). > Our own boot menu is a victim of this, currently we cannot change the > selection with an USB keyboard due to this. > > Since we already implement a queue for USB key codes, we can just insert > the three character ANSI sequence into the key buffer. This fixes the > bootmenu, and is more universal for other users (UEFI) as well. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > --- > common/usb_kbd.c | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass <sjg@chromium.org>
On 30/03/2019 21:18, Simon Glass wrote: > On Fri, 22 Mar 2019 at 19:32, Andre Przywara <andre.przywara@arm.com> wrote: Hi Simon, many thanks for the review of all those patches, much appreciated! >> So far arrows key pressed on an USB keyboard got translated to some >> low ASCII control sequences (Ctrl+N, Ctrl+P). Some programs understand >> these codes, but the standard for those keys is to use ANSI control > > Which standard? The only real standard for encoding arrow keys seems to be "ANSI terminal" escape sequences, I think ECMA-48 is the official name(?) Also since our very own U-Boot boot menu requires this ... Cheers, Andre >> sequences for cursor movement (ESC [ A). >> Our own boot menu is a victim of this, currently we cannot change the >> selection with an USB keyboard due to this. >> >> Since we already implement a queue for USB key codes, we can just insert >> the three character ANSI sequence into the key buffer. This fixes the >> bootmenu, and is more universal for other users (UEFI) as well. >> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com> >> --- >> common/usb_kbd.c | 24 +++++++++++++++++++++++- >> 1 file changed, 23 insertions(+), 1 deletion(-) > > Reviewed-by: Simon Glass <sjg@chromium.org> >
Hi André, On Sun, 31 Mar 2019 at 18:04, André Przywara <andre.przywara@arm.com> wrote: > > On 30/03/2019 21:18, Simon Glass wrote: > > On Fri, 22 Mar 2019 at 19:32, Andre Przywara <andre.przywara@arm.com> wrote: > > Hi Simon, > > many thanks for the review of all those patches, much appreciated! You're welcome, your patches are very easy to review. > > >> So far arrows key pressed on an USB keyboard got translated to some > >> low ASCII control sequences (Ctrl+N, Ctrl+P). Some programs understand > >> these codes, but the standard for those keys is to use ANSI control > > > > Which standard? > > The only real standard for encoding arrow keys seems to be "ANSI > terminal" escape sequences, I think ECMA-48 is the official name(?) > Also since our very own U-Boot boot menu requires this ... OK I see, thanks. Regards, Simon [..]
On Sat, 23 Mar 2019 01:30:01 +0000 Andre Przywara andre.przywara@arm.com wrote: > So far arrows key pressed on an USB keyboard got translated to some > low ASCII control sequences (Ctrl+N, Ctrl+P). Some programs understand > these codes, but the standard for those keys is to use ANSI control > sequences for cursor movement (ESC [ A). > Our own boot menu is a victim of this, currently we cannot change the > selection with an USB keyboard due to this. > > Since we already implement a queue for USB key codes, we can just insert > the three character ANSI sequence into the key buffer. This fixes the > bootmenu, and is more universal for other users (UEFI) as well. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > --- > common/usb_kbd.c | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) Applied to u-boot-video/master, thanks! -- Anatolij
diff --git a/common/usb_kbd.c b/common/usb_kbd.c index 020f0d4117..cc99c6be07 100644 --- a/common/usb_kbd.c +++ b/common/usb_kbd.c @@ -145,6 +145,12 @@ static void usb_kbd_put_queue(struct usb_kbd_pdata *data, char c) data->usb_kbd_buffer[data->usb_in_pointer] = c; } +static void usb_kbd_put_sequence(struct usb_kbd_pdata *data, char *s) +{ + for (; *s; s++) + usb_kbd_put_queue(data, *s); +} + /* * Set the LEDs. Since this is used in the irq routine, the control job is * issued with a timeout of 0. This means, that the job is queued without @@ -235,9 +241,25 @@ static int usb_kbd_translate(struct usb_kbd_pdata *data, unsigned char scancode, } /* Report keycode if any */ - if (keycode) { + if (keycode) debug("%c", keycode); + + switch (keycode) { + case 0x0e: /* Down arrow key */ + usb_kbd_put_sequence(data, "\e[B"); + break; + case 0x10: /* Up arrow key */ + usb_kbd_put_sequence(data, "\e[A"); + break; + case 0x06: /* Right arrow key */ + usb_kbd_put_sequence(data, "\e[C"); + break; + case 0x02: /* Left arrow key */ + usb_kbd_put_sequence(data, "\e[D"); + break; + default: usb_kbd_put_queue(data, keycode); + break; } return 0;
So far arrows key pressed on an USB keyboard got translated to some low ASCII control sequences (Ctrl+N, Ctrl+P). Some programs understand these codes, but the standard for those keys is to use ANSI control sequences for cursor movement (ESC [ A). Our own boot menu is a victim of this, currently we cannot change the selection with an USB keyboard due to this. Since we already implement a queue for USB key codes, we can just insert the three character ANSI sequence into the key buffer. This fixes the bootmenu, and is more universal for other users (UEFI) as well. Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- common/usb_kbd.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)