d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

vt: resolve conflict between VT_ALT_TO_ESC_HACK and DBG

Browse Source 
When using the ALT+CTRL+ESC sequence to break into kdb, the keyboard is
completely borked when you return. watch(8) shows that it's working, but
it's inserting escape sequences.

Further investigation revealed that VT_ALT_TO_ESC_HACK is the default and
directly conflicts with this sequence, so upon return from the debugger
ALKED is set.

If they triggered the break to debugger, it's safe to assume they didn't
mean to use VT_ALT_TO_ESC_HACK, so just unset it to reduce the surprise when
the keyboard seems non-functional upon return.

Reviewed by:	tsoome
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D27109
This commit is contained in:
Kyle Evans 2020-11-07 15:38:01 +00:00
parent eb20867f52
commit e0f14ecf60
1 changed files with 12 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
sys/dev/vt/vt_core.c
View File

@ -725,13 +725,22 @@ vt_scroll(struct vt_window *vw, int offset, int whence)
}
static int
vt_machine_kbdevent(int c)
vt_machine_kbdevent(struct vt_device *vd, int c)
{
switch (c) {
case SPCLKEY | DBG: /* kbdmap(5) keyword `debug`. */
if (vt_kbd_debug)
if (vt_kbd_debug) {
kdb_enter(KDB_WHY_BREAK, "manual escape to debugger");
#if VT_ALT_TO_ESC_HACK
/*
* There's an unfortunate conflict between SPCLKEY|DBG
* and VT_ALT_TO_ESC_HACK. Just assume they didn't mean
* it if we got to here.
*/
vd->vd_kbstate &= ~ALKED;
#endif
}
return (1);
case SPCLKEY | HALT: /* kbdmap(5) keyword `halt`. */
if (vt_kbd_halt)
@ -864,7 +873,7 @@ vt_processkey(keyboard_t *kbd, struct vt_device *vd, int c)
return (0);
#endif
if (vt_machine_kbdevent(c))
if (vt_machine_kbdevent(vd, c))
return (0);
if (vw->vw_flags & VWF_SCROLL) {