Konsole 26.04.1 silently drops all keyboard input (win32-input-mode now implemented)
Environment
- Konsole 26.04.1 (KDE Applications 26.04.1)
- tvision (any recent build)
- Linux x86-64
Steps to reproduce
Build any tvision example and launch it from Konsole 26.04.1:
cd build && ./hello # or tvdemo, tvedit, etc.
Nothing happens whenever Enter, Tab, Escape, or any arrow key is pressed. Nevertheless, mouse clicks and Alt+letter shortcuts do work normally.
Root cause
Konsole 26.04.1 now implements win32-input-mode (\x1B[?9001h), which was previously only supported by Conpty (Windows Terminal).
When enabled, Konsole encodes every key press as:
\x1B[<vk>;<scan>;<char>;<keydown>;<ctrl>;1_
For example, Enter gives \x1B[13;0;13;1;0;1_. This is visible in Konsole's source (see src/Vt102Emulation.cpp, lines 2311 and 2950–3158):
// line 2311
case token_csi_pr('h', 9001): setMode(MODE_Win32Input); break;
// lines 3154–3157
int len = snprintf(seq_buffer, sizeof(seq_buffer),
"\x1B[%d;%d;%d;%d;%d;%d_",
virtualKeyCode, scanCode, uchar,
is_key_down, controlKeyState, 1);TVision's parseEscapeSeq reads the CSI sequence but has no handler for the _ terminator and returns Rejected.
NcursesInput::getEvent then calls in.get() (wgetch()) expecting a standard ncurses key code. However, TVision enables mouse tracking for its own mouse support, so ncurses independently processes Konsole's mouse-move sequences (\x1B[<35;X;YM) and returns KEY_MOUSE (409) whenever the cursor is over the terminal window. The keyboard event bytes, unrecognized by ncurses as well (no terminfo entry for \x1B[...;1_), are eventually discarded by ncurses' ESC timeout.
This was confirmed by tracing NcursesInput::getEvent: every key press produced parseEvent result=Rejected immediately followed by
in.get()=0x0199 (KEY_MOUSE=409).
Suggested fix
Detect Konsole via its environment variables and skip sending \x1B[?9001h (and the other extended protocols it now implements:
\x1B[>5u Kitty, \x1B[>4;1m modifyOtherKeys, far2l) until TVision gains proper support for these encodings under Konsole.
KONSOLE_VERSION is set since KDE 5.27; KONSOLE_DBUS_SESSION is the older fallback present on all builds.
Konsole 26.04.1 silently drops all keyboard input (win32-input-mode now implemented)
Environment
Steps to reproduce
Build any tvision example and launch it from Konsole 26.04.1:
Nothing happens whenever Enter, Tab, Escape, or any arrow key is pressed. Nevertheless, mouse clicks and Alt+letter shortcuts do work normally.
Root cause
Konsole 26.04.1 now implements win32-input-mode (
\x1B[?9001h), which was previously only supported by Conpty (Windows Terminal).When enabled, Konsole encodes every key press as:
For example, Enter gives
\x1B[13;0;13;1;0;1_. This is visible in Konsole's source (seesrc/Vt102Emulation.cpp, lines 2311 and 2950–3158):TVision's
parseEscapeSeqreads the CSI sequence but has no handler for the_terminator and returnsRejected.NcursesInput::getEventthen callsin.get()(wgetch()) expecting a standard ncurses key code. However, TVision enables mouse tracking for its own mouse support, so ncurses independently processes Konsole's mouse-move sequences (\x1B[<35;X;YM) and returnsKEY_MOUSE(409) whenever the cursor is over the terminal window. The keyboard event bytes, unrecognized by ncurses as well (no terminfo entry for\x1B[...;1_), are eventually discarded by ncurses' ESC timeout.This was confirmed by tracing
NcursesInput::getEvent: every key press producedparseEvent result=Rejectedimmediately followed byin.get()=0x0199 (KEY_MOUSE=409).Suggested fix
Detect Konsole via its environment variables and skip sending
\x1B[?9001h(and the other extended protocols it now implements:\x1B[>5uKitty,\x1B[>4;1mmodifyOtherKeys, far2l) until TVision gains proper support for these encodings under Konsole.KONSOLE_VERSIONis set since KDE 5.27;KONSOLE_DBUS_SESSIONis the older fallback present on all builds.