4

After a little futile hacking, I realised that . . . I would need to properly map the HHK keyboard so that I could use the various meta-keys. Thus began my descent into hell.

Doug Palmer, An Unreliable Guide to XKB Configuration

I am attempting to configure Konsole to emit VT220-style escape sequences from the numeric keypad when application keypad mode is enabled (e.g., by echoti smkx). In particular, the following control sequences should be the output under the described conditions:

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-VT220-Style-Function-Keys

One must be aware that munging the TERM environment variable is the same as lying to the shell about the terminal's capabilities and should generally be avoided. Simply setting TERM=xterm-vt220 is insufficient, and causes unexpected behavior.

I have a simple, but partial solution. Konsole permits configuration of its terminal key bindings in the form of .keytab files. The following additions are effective, saved into .local/share/konsole/VT220.keytab:

keyboard "VT220"
key 0+KeyPad+AppCursorKeys : "\EOp"
key 1+KeyPad+AppCursorKeys : "\EOq"
key 2+KeyPad+AppCursorKeys : "\EOr"
key 3+KeyPad+AppCursorKeys : "\EOs"
key 4+KeyPad+AppCursorKeys : "\EOt"
key 5+KeyPad+AppCursorKeys : "\EOu"
key 6+KeyPad+AppCursorKeys : "\EOv"
key 7+KeyPad+AppCursorKeys : "\EOw"
key 8+KeyPad+AppCursorKeys : "\EOx"
key 9+KeyPad+AppCursorKeys : "\EOy"
key ++KeyPad+AppCursorKeys : "\EOk"
key *+KeyPad+AppCursorKeys : "\EOj"
key .+KeyPad+AppCursorKeys : "\EOn"
key -+KeyPad+AppCursorKeys : "\EOm"
key Enter+KeyPad : "\EOM"

With these key bindings applied (along with any others that may be present), konsole will emit the same control sequences as xterm when application keypad mode is enabled and NumLock is on. These sequences are useful to applications that expect VT220 emulation because they uniquely identify keystrokes from the numeric keypad, enabling arbitrary functions to be bound to them.

One common keypad key is missing in my configuration: / (Qt::Key_Slash). The Konsole graphical key binding editor does not seem to recognize any reference to that key, either by name or expressed as a literal. If it is manually written into the .keytab file, Konsole will ignore it and the line will not appear in the GUI editor. This leaves a quite annoying hole in my keypad, where exactly one key is stubbornly unprogrammable.

I'd rather not get into the weeds with xkb and friends; but of course vanilla xterm does all of this out-of-the-box, demonstrating that it oughtn't be necessary to fiddle with key bindings at such a low level in this case. It seems instead that Konsole (or QT) is doing something unique and snowflakey on top of X.

Question: Is it possible in Konsole to re-bind the numerical keypad's / key to a different control sequence? Alternatively, is this the point where something that operates at a different level (like terminfo, xkb, or xterm-keys from tmux) would be more effective? Have I, perhaps, gone mad?

Any insight from other intrepid console commanders would be appreciated.

  • 1
    I can't help here, but an up-vote for making me laugh. – Stephen Rauch Feb 12 '17 at 4:21
  • Thank you. A good question should at least be an interesting read. – nethershaw Feb 12 '17 at 17:54
3

Konsole ignores that, because it relies upon a hard-coded list of keys which cannot be mapped:

// Override any of the following shortcuts because
// they are needed by the terminal
int keyCode = keyEvent->key() | modifiers;
switch (keyCode) {
    // list is taken from the QLineEdit::event() code
case Qt::Key_Tab:
case Qt::Key_Delete:
case Qt::Key_Home:
case Qt::Key_End:
case Qt::Key_Backspace:
case Qt::Key_Left:
case Qt::Key_Right:
case Qt::Key_Slash:
case Qt::Key_Period:
case Qt::Key_Space:
    keyEvent->accept();
    return true;
}
return false;
  • Thank you kindly. That certainly explains why I am unable to rebind that key. Follow-up: why is Konsole unable to distinguish between Slash+KeyPad and Slash-KeyPad whereas xterm appears able? The two keys should be distinguishable, emitting different keycodes; indeed, even in Konsole, xev recognizes them as such -- Slash+Keypad returns keycode 106 (keysym 0xffaf, KP_Divide), whereas Slash-Keypad returns keycode 61 (keysym 0x2f, slash). The terminal should only require one of these (keysym 0x2f), allowing the other to be mapped, so the question remains: how best to fill the gap? – nethershaw Feb 12 '17 at 16:19
  • 2
    X11 provides distinct events for the main-keyboard and the keypad. Before checking the source code, I took a look at Qt's header file, and found that it (apparently) does not make that distinction (puzzling since I seem to recall that Windows also makes the distinction...). – Thomas Dickey Feb 12 '17 at 16:28
  • Interesting. I recall the same about Windows. Cygwin in VT220 mode handles this case natively. Maybe I will try to rebind just this one keypad key at the X layer with xkb, before QT, so QT has no opportunity to interfere with it. Will update if that strategy bears fruit. – nethershaw Feb 12 '17 at 16:31
  • I am marking this the accepted answer. I have exhausted all possibilities and cannot get Konsole to output anything other than a literal / when either of the keyboard's slash keys are pressed, with any combination of modifiers. Konsole is simply too limited. The actual solution appears to be just to use xterm with the xkb_types "complete+numpad(mac)" type selection configured in xkb, equivalent to enabling "Numeric keypad keys always enter digits (as in Mac OS)" in KDE advanced keyboard settings. INS/DEL/HOM/END/PGUP/PGDN still work on the editing keypad. – nethershaw Feb 12 '17 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.