Bug 189116 - konsole disregards center keypad key
Summary: konsole disregards center keypad key
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Applications
Component: keyboard (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-08 12:10 UTC by Thomas Wolff
Modified: 2018-04-08 00:51 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wolff 2009-04-08 12:10:29 UTC
Version:            (using KDE 4.0.5)
Installed from:    SuSE RPMs

The center key of the numeric keypad is totally ignored by konsole (unless in NumLock mode, of course).

The key usually delivers the KP_Begin X keysym and other terminal emulators usually send ESC[E to the application on this key.

It should be possible for applications to make use of this key.
Comment 1 Gregory Kizior 2010-12-09 04:54:38 UTC
Sorry KDE folks, I just reported the same bug; forgive me, I'm a newbie here.
I didn't search for existing bugs with an appropriate keyword.

Yes, this is the bug I need fixed. I REALLY need my editor to see "Numeric Keypad 5" (without NumLock on).

Without this fix, KDE konsole is seriously hobbled.
I'm using gnome-terminal, but it has a (block-) cursor bug...sigh.

I notice that Mr Wolff's report was made 20 MONTHS ago! sigh.
Comment 2 Jekyll Wu 2011-08-03 22:51:21 UTC
maybe related with #213579?
Comment 3 Jekyll Wu 2011-08-13 02:32:26 UTC

*** This bug has been marked as a duplicate of bug 213579 ***
Comment 4 Thomas Wolff 2012-05-02 11:32:36 UTC
This bug is *not* a duplicate of the other one. In my case, the other numeric keypad keys did work but the center key did not because it gets maliciously ignored.
Comment 5 M. Raymond Vaughn 2017-02-12 00:12:07 UTC
This ought to be marked confirmed.

It also ought to be receiving more attention than it has in the last _eight_ years.

A VT220-compatible terminal emulator should transmit unique DEC escape sequences in application mode when NumLock is disabled: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-VT220-Style-Function-Keys

Instead, Konsole emits an _incomplete_ set of PC-style escape sequences: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-PC-Style-Function-Keys -- notably with only the sequence for KP_5 missing. There is no apparent reason for this.

Additionally, Konsole DOES appear sensitive to smkx/rmkx control sequences to enter/exit application keypad mode, but incorrectly confuses two different control character schemes. In default mode with NumLock off, the control characters are 'ESC [' for ALL keypad digits including 7 and 1 (normally HOME and END, respectively); in application keypad mode, however, the control characters are 'ESC O'. Again in both cases, keypad digit 5 emits no escape string.

Compare to the behavior of xterm, which Konsole ostensibly attempts to resemble (indeed it lies to the shell by default by setting TERM=xterm while not implementing all of its capabilities): in all cases, it emits a consistent escape sequence for the center keypad key, whether NumLock or application keypad mode are enabled or not.

KDE has apparently been sitting on this family of issues, which xterm has always unfailingly handled despite being far less easy on the eyes, for the better part of a decade. It looks more like Konsole was written with a categorically inconsistent keybinding scheme than a simple omission -- and this is still true in the very latest generally-usable KDE 5 Plasma environment (konsole-16.08.3-r1).

Conclusion: I have yet to discover any way to define a Konsole keybinding for this key with NumLock off.

Is it really so difficult for Konsole to just reproduce xterm's keybinding behavior exactly? I know we all want to pretend Wayland is coming and will solve all our problems...

...but X still exists and remains what most of us have to work with.
Comment 6 Ahmad Samir 2018-04-05 13:37:54 UTC
The original issue in this report should be fixed with:
https://phabricator.kde.org/D11958

In the interim, you can add this rule via the key bindings editor:
Clear+KeyPad    "\E[E"
Comment 7 Kurt Hindenburg 2018-04-05 22:28:18 UTC
Git commit 2037c36a6467a940e5e5b645be3d9d83fc9f46b9 by Kurt Hindenburg, on behalf of Ahmad Samir.
Committed on 05/04/2018 at 22:28.
Pushed by hindenburg into branch 'master'.

Make the keypad "5" key send "\E[E" when NumLock is off

Summary:
When NumLock is off the keypad "5" key should send '\E[E' sequence; this
matches xterm behaviour.

Reviewers: #konsole, hindenburg

Reviewed By: #konsole, hindenburg

Subscribers: hindenburg, #konsole

Tags: #konsole

Differential Revision: https://phabricator.kde.org/D11958

M  +4    -0    data/keyboard-layouts/default.keytab

https://commits.kde.org/konsole/2037c36a6467a940e5e5b645be3d9d83fc9f46b9
Comment 8 Kurt Hindenburg 2018-04-08 00:51:55 UTC
Git commit 6aad0aa4c66ff38c31a344736f6e0efceff7298d by Kurt Hindenburg, on behalf of Ahmad Samir.
Committed on 08/04/2018 at 00:48.
Pushed by hindenburg into branch 'Applications/18.04'.

Make the keypad "5" key send "\E[E" when NumLock is off

Summary:
When NumLock is off the keypad "5" key should send '\E[E' sequence; this
matches xterm behaviour.

Reviewers: #konsole, hindenburg

Reviewed By: #konsole, hindenburg

Subscribers: hindenburg, #konsole

Tags: #konsole

Differential Revision: https://phabricator.kde.org/D11958

(cherry picked from commit 2037c36a6467a940e5e5b645be3d9d83fc9f46b9)

M  +4    -0    data/keyboard-layouts/default.keytab

https://commits.kde.org/konsole/6aad0aa4c66ff38c31a344736f6e0efceff7298d