vt: resolve conflict between VT_ALT_TO_ESC_HACK and DBG

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
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=367448

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) {