WSL2-Linux-Kernel/kernel/debug/kdb/kdb_keyboard.c

264 строки
5.5 KiB
C
Исходник Обычный вид История

/*
* Kernel Debugger Architecture Dependent Console I/O handler
*
* This file is subject to the terms and conditions of the GNU General Public
* License.
*
* Copyright (c) 1999-2006 Silicon Graphics, Inc. All Rights Reserved.
* Copyright (c) 2009 Wind River Systems, Inc. All Rights Reserved.
*/
#include <linux/kdb.h>
#include <linux/keyboard.h>
#include <linux/ctype.h>
#include <linux/module.h>
#include <linux/io.h>
/* Keyboard Controller Registers on normal PCs. */
#define KBD_STATUS_REG 0x64 /* Status register (R) */
#define KBD_DATA_REG 0x60 /* Keyboard data register (R/W) */
/* Status Register Bits */
#define KBD_STAT_OBF 0x01 /* Keyboard output buffer full */
#define KBD_STAT_MOUSE_OBF 0x20 /* Mouse output buffer full */
static int kbd_exists;
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
static int kbd_last_ret;
/*
* Check if the keyboard controller has a keypress for us.
* Some parts (Enter Release, LED change) are still blocking polled here,
* but hopefully they are all short.
*/
int kdb_get_kbd_char(void)
{
int scancode, scanstatus;
static int shift_lock; /* CAPS LOCK state (0-off, 1-on) */
static int shift_key; /* Shift next keypress */
static int ctrl_key;
u_short keychar;
if (KDB_FLAG(NO_I8042) || KDB_FLAG(NO_VT_CONSOLE) ||
(inb(KBD_STATUS_REG) == 0xff && inb(KBD_DATA_REG) == 0xff)) {
kbd_exists = 0;
return -1;
}
kbd_exists = 1;
if ((inb(KBD_STATUS_REG) & KBD_STAT_OBF) == 0)
return -1;
/*
* Fetch the scancode
*/
scancode = inb(KBD_DATA_REG);
scanstatus = inb(KBD_STATUS_REG);
/*
* Ignore mouse events.
*/
if (scanstatus & KBD_STAT_MOUSE_OBF)
return -1;
/*
* Ignore release, trigger on make
* (except for shift keys, where we want to
* keep the shift state so long as the key is
* held down).
*/
if (((scancode&0x7f) == 0x2a) || ((scancode&0x7f) == 0x36)) {
/*
* Next key may use shift table
*/
if ((scancode & 0x80) == 0)
shift_key = 1;
else
shift_key = 0;
return -1;
}
if ((scancode&0x7f) == 0x1d) {
/*
* Left ctrl key
*/
if ((scancode & 0x80) == 0)
ctrl_key = 1;
else
ctrl_key = 0;
return -1;
}
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
if ((scancode & 0x80) != 0) {
if (scancode == 0x9c)
kbd_last_ret = 0;
return -1;
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
}
scancode &= 0x7f;
/*
* Translate scancode
*/
if (scancode == 0x3a) {
/*
* Toggle caps lock
*/
shift_lock ^= 1;
#ifdef KDB_BLINK_LED
kdb_toggleled(0x4);
#endif
return -1;
}
if (scancode == 0x0e) {
/*
* Backspace
*/
return 8;
}
/* Special Key */
switch (scancode) {
case 0xF: /* Tab */
return 9;
case 0x53: /* Del */
return 4;
case 0x47: /* Home */
return 1;
case 0x4F: /* End */
return 5;
case 0x4B: /* Left */
return 2;
case 0x48: /* Up */
return 16;
case 0x50: /* Down */
return 14;
case 0x4D: /* Right */
return 6;
}
if (scancode == 0xe0)
return -1;
/*
* For Japanese 86/106 keyboards
* See comment in drivers/char/pc_keyb.c.
* - Masahiro Adegawa
*/
if (scancode == 0x73)
scancode = 0x59;
else if (scancode == 0x7d)
scancode = 0x7c;
if (!shift_lock && !shift_key && !ctrl_key) {
keychar = plain_map[scancode];
} else if ((shift_lock || shift_key) && key_maps[1]) {
keychar = key_maps[1][scancode];
} else if (ctrl_key && key_maps[4]) {
keychar = key_maps[4][scancode];
} else {
keychar = 0x0020;
kdb_printf("Unknown state/scancode (%d)\n", scancode);
}
keychar &= 0x0fff;
if (keychar == '\t')
keychar = ' ';
switch (KTYP(keychar)) {
case KT_LETTER:
case KT_LATIN:
if (isprint(keychar))
break; /* printable characters */
/* drop through */
case KT_SPEC:
if (keychar == K_ENTER)
break;
/* drop through */
default:
return -1; /* ignore unprintables */
}
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
if (scancode == 0x1c) {
kbd_last_ret = 1;
return 13;
}
return keychar & 0xff;
}
EXPORT_SYMBOL_GPL(kdb_get_kbd_char);
/*
* Best effort cleanup of ENTER break codes on leaving KDB. Called on
* exiting KDB, when we know we processed an ENTER or KP ENTER scan
* code.
*/
void kdb_kbd_cleanup_state(void)
{
int scancode, scanstatus;
/*
* Nothing to clean up, since either
* ENTER was never pressed, or has already
* gotten cleaned up.
*/
if (!kbd_last_ret)
return;
kbd_last_ret = 0;
/*
* Enter key. Need to absorb the break code here, lest it gets
* leaked out if we exit KDB as the result of processing 'g'.
*
* This has several interesting implications:
* + Need to handle KP ENTER, which has break code 0xe0 0x9c.
* + Need to handle repeat ENTER and repeat KP ENTER. Repeats
* only get a break code at the end of the repeated
* sequence. This means we can't propagate the repeated key
* press, and must swallow it away.
* + Need to handle possible PS/2 mouse input.
* + Need to handle mashed keys.
*/
while (1) {
while ((inb(KBD_STATUS_REG) & KBD_STAT_OBF) == 0)
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
cpu_relax();
/*
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
* Fetch the scancode.
*/
scancode = inb(KBD_DATA_REG);
scanstatus = inb(KBD_STATUS_REG);
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
/*
* Skip mouse input.
*/
if (scanstatus & KBD_STAT_MOUSE_OBF)
continue;
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
/*
* If we see 0xe0, this is either a break code for KP
* ENTER, or a repeat make for KP ENTER. Either way,
* since the second byte is equivalent to an ENTER,
* skip the 0xe0 and try again.
*
* If we see 0x1c, this must be a repeat ENTER or KP
* ENTER (and we swallowed 0xe0 before). Try again.
*
* We can also see make and break codes for other keys
* mashed before or after pressing ENTER. Thus, if we
* see anything other than 0x9c, we have to try again.
*
* Note, if you held some key as ENTER was depressed,
* that break code would get leaked out.
*/
if (scancode != 0x9c)
continue;
KDB: Fix usability issues relating to the 'enter' key. This fixes the following problems: 1) Typematic-repeat of 'enter' gives warning message and leaks make/break if KDB exits. Repeats look something like 0x1c 0x1c .... 0x9c 2) Use of 'keypad enter' gives warning message and leaks the ENTER break/make code out if KDB exits. KP ENTER repeats look someting like 0xe0 0x1c 0xe0 0x1c ... 0xe0 0x9c. 3) Lag on the order of seconds between "break" and "make" when expecting the enter "break" code. Seen under virtualized environments such as VMware ESX. The existing special enter handler tries to glob the enter break code, but this fails if the other (KP) enter was used, or if there was a key repeat. It also fails if you mashed some keys along with enter, and you ended up with a non-enter make or non-enter break code coming after the enter make code. So first, we modify the handler to handle these cases. But performing these actions on every enter is annoying since now you can't hold ENTER down to scroll <more>d messages in KDB. Since this special behaviour is only necessary to handle the exiting KDB ('g' + ENTER) without leaking scancodes to the OS. This cleanup needs to get executed anytime the kdb_main loop exits. Tested on QEMU. Set a bp on atkbd.c to verify no scan code was leaked. Cc: Andrei Warkentin <andreiw@vmware.com> [jason.wessel@windriver.com: move cleanup calls to kdb_main.c] Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-02-28 16:55:05 +04:00
return;
}
}