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

1 files changed, 12 insertions, 3 deletions

diff --git a/sys/dev/vt/vt_core.c b/sys/dev/vt/vt_core.c
index bc3a729d000e..a7cb21e12b5d 100644
--- a/sys/dev/vt/vt_core.c
+++ b/sys/dev/vt/vt_core.c
@@ -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) {