Bug 183458 - Numpad (keypad) keys not mapped correctly when setting Global Shortcuts
Summary: Numpad (keypad) keys not mapped correctly when setting Global Shortcuts
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: shortcuts (show other bugs)
Version: 4.5
Platform: Ubuntu Linux
: NOR normal with 868 votes (vote)
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 166098 178542 190694 195445 208026 212386 254536 357133 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-06 17:38 UTC by Harikawashi
Modified: 2017-08-15 14:17 UTC (History)
63 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch for kde-runtime/kglobalaccel (7.05 KB, patch)
2012-08-24 17:47 UTC, David Faure
Details
Patch for kdelibs/kdeui/util (876 bytes, patch)
2012-08-24 17:49 UTC, David Faure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harikawashi 2009-02-06 17:38:57 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Ubuntu Packages

When setting global shortcut keys, numpad keys seem to be mapped the same as their regular counterparts (eg. +, -). Pre KDE 4.2, numpad keys were mapped as "KP_add" or whatever the key might have been. This is no longer the case, and causes problems.

Specifically, I can't get Amarok 2.0.1 to recognise the numpad + and - (combined with windowskey) as global shortcuts for volume control. I've tried setting them via Amarok, and via systemsettings, neither works.

Please let me know if you need any more info.
Comment 1 Sergio PR 2009-05-08 23:53:37 UTC
I have the same problem :S

ArchLinux, KDE 4.2.2 from KDEmod
Comment 2 steini2000 2009-05-28 01:30:29 UTC
Same problem here (Kubuntu KDE 4.2.2 and 4.2.3).

Setting the global shortcut: Pressing left Win and any plus (alphanumeric or numpad) produces Meta++ in dialog.
BUT: Only left Win and alphanumeric plus work.
Pressing left Win and numpad plus -> nothing happens.

Setting different keyboard layouts doesn't help (tried en and de).
All (or most) keys from numpad are broken (at least 0-9, +, -, /, *).

kglobalshortcutsrc:
decreaseVolume=Meta+-,Meta+-,Decrease Volume
increaseVolume=Meta++,Meta++,Increase Volume
Comment 3 mac@phobos.ca 2009-06-29 17:23:49 UTC
*** This bug has been confirmed by popular vote. ***
Comment 4 mac@phobos.ca 2009-06-29 18:14:25 UTC
Same problem here, KDE 4.2.2 from Debian testing.
Comment 5 Dario Andres 2009-10-22 01:17:48 UTC
*** Bug 166098 has been marked as a duplicate of this bug. ***
Comment 6 Dario Andres 2009-10-22 01:17:56 UTC
*** Bug 208026 has been marked as a duplicate of this bug. ***
Comment 7 Dario Andres 2009-11-01 23:18:49 UTC
*** Bug 212386 has been marked as a duplicate of this bug. ***
Comment 8 Chris Stewart 2009-11-02 21:49:22 UTC
Same problem here on Ubuntu 9.10 (Karmic) with stock KDE 4.3.2.
Comment 9 Pistos 2009-11-04 04:43:49 UTC
Gentoo, KDE 4.3.1.  Previously (in 3.5), I mapped my numpad keys to be global shortcuts for switching to desktops.  I can no longer do this in 4.3.
Comment 10 Jean-Noel Rivasseau 2010-02-03 21:44:48 UTC
Could this bug severity be boosted? It appears still not fixed in 4.4 although it actually affects a lots of apps (Amarok for instance...)
Comment 11 Sergio PR 2010-03-03 19:40:35 UTC
The bug persits on KDE 4.4.1
Comment 12 Chris Stewart 2010-03-03 20:48:36 UTC
I think this is probably caused by a change in Qt4's handling of input (vs. Qt3).  I think this should be demonstrable in a simple (non-KDE specific) way.  I'll see if I can come up with a way to clearly show a difference, and therefore the unwanted behavior.  This bug is making me crazy.
Comment 13 Eckhart Wörner 2010-03-29 04:41:42 UTC
*** Bug 190694 has been marked as a duplicate of this bug. ***
Comment 14 pan shi zhu 2010-04-08 05:00:43 UTC
I confirm this bug in my way: cannot set hotkeys in keypad AT ALL.

procedure:

1. set numlock off.
2. use system settings to set any shortcut to Ctrl+Alt+Keypad_PgUp
3. press Ctrl+Alt+Keypad_PgUp and found that the shortcut not activated at all.
4. press Ctrl+Alt+PgUp works, but this is not I want.
Comment 15 Michael Trunner 2010-04-12 19:17:36 UTC
The bug persits on KDE 4.4.2

Archlinux, KDE 4.4.2 from extra
Comment 16 Michael Trunner 2010-04-13 20:46:33 UTC
As I can see Qt has an KeypadModifier like the MetaModifier or ShifModifier.
I think khotkeys doesn't handle that modifier information and doesn't safe it into the khotkeysrc. Because of this, the non keypad version of the short cut works instate of the expected one.
Comment 17 Pistos 2010-08-23 16:03:33 UTC
I found a workaround.

Using xev and xmodmap, I changed the numpad keys to different keysyms.  For example, my ~/.Xmodmap file now has this in it:

keycode 87 = XF86Launch1
keycode 88 = XF86Launch2
keycode 89 = XF86Launch3
keycode 83 = XF86Launch4
keycode 84 = XF86Launch5
keycode 85 = XF86Launch6
keycode 79 = XF86Launch7
keycode 80 = XF86Launch8
keycode 81 = XF86Launch9
keycode 90 = XF86LaunchA
keycode 91 = XF86LaunchB

Then (after running `xmodmap ~/.Xmodmap`), KDE's Keyboard Shortcuts configuration can detect and map the numpad keys, thinking they are something else (in this case, Launch keys instead of KP_1, KP_2, etc.).  So, I'm, in effect, tricking KDE, but I get the desired result, which is the ability to map my numpad to whatever I want.

Hope this helps some folks.
Comment 18 Alexey Shildyakov 2010-12-18 15:14:28 UTC
In Git version with KDE 4.5.4 Amarok is able to change volume by win + (+/-). But not in the numpad keys.
Comment 19 Myriam Schweingruber 2011-01-19 10:57:18 UTC
*** Bug 254536 has been marked as a duplicate of this bug. ***
Comment 20 Myriam Schweingruber 2011-01-19 10:57:50 UTC
*** Bug 195445 has been marked as a duplicate of this bug. ***
Comment 21 Chris Stewart 2011-01-31 14:07:51 UTC
KDE 4.5.5/Ubuntu 10.10 still maps the wrong keys when you use the numpad.  

Wow, we are coming up on a YEAR.  Oh well, back to Trinity for the time being.
Comment 22 Björn Pfeiffer 2012-02-23 23:25:00 UTC
Happy third anniversary!

KDE 4.8.0 in Sabayon 8 ... still there. 

In shortcut-settings, KP_LEFT  maps to Left-Arrow. When set, KP_LEFT ist not recognized as LEFT, so the input machinery makes a difference, it may be just that dialogue in system-settings that doesn't. It should work same as xev does.

This is annoying.
Comment 23 woegjiub 2012-04-07 01:55:54 UTC
Still not working, under KDE 4.8.x

This is rather distressing.
Comment 24 Duncan Clough 2012-04-22 10:39:48 UTC
This bug is still present in kubuntu 12.04...
Comment 25 Joshua Cole 2012-05-08 03:56:25 UTC
Concur, this is a critical bug for me, since that's 16 keys I used frequently for directional shortcuts that are inoperable without hacking around it via xmodmap (breaking compatibility with everything else).
Comment 26 Lukasz Purgal 2012-06-17 15:11:31 UTC
KDE 4.8.4 and state of this bugs hasn't changed :-( Tiling (kwin) is really useless without this bug beeing fixed :-(  
Guys, I hope you will cope with this soon.
Comment 27 Tobias Bora 2012-07-23 22:09:03 UTC
I confirm this very annoying bug (Kubuntu 12.04).

I hope you'll be able to solve it soon.

Thanks.
Comment 28 David Faure 2012-08-06 14:41:52 UTC
Michael -- I presume this is a bug in kkeyserver_x11, not in Qt itself?
There's some XK_KP_* stiff in that code, though.
Comment 29 Martin Koller 2012-08-16 13:17:28 UTC
*** Bug 178542 has been marked as a duplicate of this bug. ***
Comment 30 l22087 2012-08-21 09:57:23 UTC
Ohh. Disapointing to see how long this has been around. This is my second day running KDE after converting from gnome. Hope it's fixed soon.
Comment 31 David Faure 2012-08-24 16:44:46 UTC
The numeric keys can't be differenciated from the standard digits, because Qt (qkeymapper_x11.cpp) assigns XK_KP_0 to Qt::Key_0, so we lose the distinction with the other '0' key. And the global shortcut is stored as a string (e.g. Ctrl+0), no distinction there either. After all the main point of the numeric keypad is to work like the real keys (even though X provides different keycodes for them, at the "physical" level).

OK, well, I suppose you guys would be happy if it at least worked, even if not differenciated. Right?

But there the problem is our code, like keyQtToSymX(), which assumes a given Qt key is mapped to a single X key (keysym).
symQt=48 -> keySym=48, so kglobalaccel doesn't listen for keysym 0xffb0, KP_0.
KGlobalAccelImpl::grabKey() only grabs keysym 48, the standard '0' key. OK so possibly a hack in kde-runtime/kglobalaccel/kglobalaccel_x11.cpp can help...
Comment 32 David Faure 2012-08-24 17:47:16 UTC
Created attachment 73443 [details]
Patch for kde-runtime/kglobalaccel
Comment 33 David Faure 2012-08-24 17:49:57 UTC
Created attachment 73444 [details]
Patch for kdelibs/kdeui/util

These two patches make the numeric digits (0 to 9) work.

It seems there's a little bit more work needed for the other keys (Add, Subtract etc.) in kglobalaccel, we need to find out the "alternate keysym" for the Qt keys '+', '-' etc.

To be finished when I'm back to the office, i.e. in 10 days or so.

Meanwhile, please, if you're hit by this bug, please try these patches. I am not 100% confident that I didn't break something for other keys than the one I tested... given that the patches ended up being a lot more intrusive than I was initially hoping.
Comment 34 Navid Zamani 2012-08-24 18:09:51 UTC
(In reply to comment #31)
> The numeric keys can't be differenciated from the standard digits, because
> Qt (qkeymapper_x11.cpp) assigns XK_KP_0 to Qt::Key_0, so we lose the
> distinction with the other '0' key. And the global shortcut is stored as a
> string (e.g. Ctrl+0), no distinction there either. After all the main point
> of the numeric keypad is to work like the real keys (even though X provides
> different keycodes for them, at the "physical" level).

And another example of why dumbing-down things is bad. Simplifying is only good, if it doesn’t cost power. Otherwise you lose efficiency. Like here. :/

Very unfortunate…

> OK, well, I suppose you guys would be happy if it at least worked, even if
> not differenciated. Right?

Yes. Thanks a lot for the effort, man! :)

> But there the problem is our code, like keyQtToSymX(), which assumes a given
> Qt key is mapped to a single X key (keysym).

Why would it do that? That limitations has no use, yet takes away a lot of freedom. :(
Can we just get rid of the assumption for good?

I feel like it’s easier for us end-users, and application developers, to just switch to over to another toolkit. ;)
Comment 35 David Faure 2012-08-24 18:49:30 UTC
Actually, I'm wrong about Qt, it sets "Qt::KeypadModifier" when seeing a numeric keypad key, so it does offer some distinction. We just need to handle this in KDE's code, if we want to differenciate it from the standard keys.
I suppose this is wanted?

When someone sets a shortcut for "CTRL +", do they assume both "+" keys will work? I suppose so, because we don't have a different string representation anyway (CTRL KPAdd?). Hmm, Qt doesn't actually handle this in the conversion to/from string, AFAICS.

Anyway, keyQtToSymX() is our own code, we could make it return a list -- or like I did, handle the case of multiple keys externally. No need to switch to another toolkit, we can either make it work as is (with the keys not being differenciated, like my patch does), or improve Qt itself if necessary (e.g. for differenciation also in the string representation).
Comment 36 Alexey Shildyakov 2012-08-24 19:06:25 UTC
My opinion in CTRL+'+'. If I use it I will want to handle both '+' - alphanumeric and in numpad. But the problem in this only case is the alpha-key has '=' as primary representation. So ctrl+'+' in text may produce ctrl+'=' if we are talking about symbols not keycodes of buttons.
Improve Qt to differentiate string representation is good idea. Modify function by adding argument determined the differentiation.
Comment 37 Navid Zamani 2012-08-24 19:15:03 UTC
(In reply to comment #35)
> I suppose this is wanted?
I suppose yes. From a usability/user standpoint, we see different keys on our keyboards, so we should be able to do different things with them. :)
(Especially, since advanced keyboard layouts don’t see the numpad as just a clone of the normal keys anyway. Let alone advanced *keyboards* posing as normal ones.)

> When someone sets a shortcut for "CTRL +", do they assume both "+" keys will work?
That question should never come up. The thing that stores the shortcuts should have all the same fields as the Qt key event, no? Including KeypadModifier, all other modifiers, locks, modes, and whatever there is. (I’d just store the key event directly in there, also directly compare the objects later [except for time stamps etc. of course]), and save the work. Dunno if that makes sense in Qt though… ;)

As for displaying things… Hmm… if keyQtToSymX() would eat the same stuff (like, the whole key events, or at least all the fields, including KeypadModifier), it could output the correct X keysym all the time, no? Resulting in 100% transparency, and the correct key(sym) displayed in the UI.

> No need to switch to another toolkit,
I was just frustrated. In light of Qt::KeypadModifier, I’m a bit more relaxed again. :)

P.S.: I always offer free beers to every open-source developer who did software I use and happens to be in Cologne. (Since I don’t have any money, but like to say thanks anyway. :)
Comment 38 Milovan 2012-09-05 08:53:40 UTC
This is still an issue in KDE 4.9. This bug is stretching from 4.2 to 4.9, I think it is time to be squashed! :)
Comment 39 Navid Zamani 2012-09-05 09:36:32 UTC
(In reply to comment #38)
> This bug is stretching from 4.2 to 4.9, …

It’s by far not the only one.
But please wait for the release (5.0). No point in attacking unfinished early beta versions that are not meant to be used by the general public.
Comment 40 David Faure 2012-09-06 13:26:10 UTC
4.9 is a stable release, not a beta for 5.0.
Comment 41 Navid Zamani 2012-09-06 13:38:58 UTC
(In reply to comment #40)
> 4.9 is a stable release, not a beta for 5.0.

Sorry, there seems to be a misunderstanding. 4.x is the beta branch for 5.0.
Comment 42 Milovan 2012-09-12 08:55:50 UTC
(In reply to comment #39)
> (In reply to comment #38)
> > This bug is stretching from 4.2 to 4.9, …
> 
> It’s by far not the only one.
> But please wait for the release (5.0). No point in attacking unfinished
> early beta versions that are not meant to be used by the general public.

4.9 is a stable version of KDE. I have no idea how you came up with beta argument at all. Also afaik there is no KDE 5 but its planned to be KDE 4.10 which still has no relation with what I wrote.

I am aware there are other bugs also stretching through multiple KDE versions, and I didn't attack anyone. Perhaps you should reread my previous comment and think again.
Comment 43 Navid Zamani 2012-09-12 11:24:22 UTC
(In reply to comment #42)
> 4.9 is a stable version of KDE. I have no idea how you came up with beta
> argument at all. Also afaik there is no KDE 5 but its planned to be KDE 4.10
> which still has no relation with what I wrote.

I’m sorry. I inferred that KDE 4.x must be a developer line, like the odd versions of Gnome and Linux back in the times. (Where e.g. 2.3 and 2.5 were for development and 2.4 and 2.6 were for normal users.) I thought it was the same for KDE 4.x, because of its general buggyness and because of what other people wrote. It was sort of a natural conclusion that just was obvious to me, so I didn’t question it.

Thanks for the hint. I must have looked like an idiot to you guys. ;)
But hey, the thing really is quite buggy or even feels unfinished in so many places where it just shouldn’t for a stable release version. But you’re right. I should not complain, since it’s free, and should instead support you guys more, so that you have the time and resources.

> and I didn't attack anyone.
Sorry, I didn’t mean to say that like that. Everything’s good. :)

Anyway… This was really off-topic for this bug. Sorry everyone.
Comment 44 Milovan 2012-09-17 11:14:04 UTC
All ok, no worries. :)
Comment 45 Milovan 2012-11-06 15:11:05 UTC
(In reply to comment #33)
> Created attachment 73444 [details]
> Patch for kdelibs/kdeui/util
> 
> These two patches make the numeric digits (0 to 9) work.
> 
> It seems there's a little bit more work needed for the other keys (Add,
> Subtract etc.) in kglobalaccel, we need to find out the "alternate keysym"
> for the Qt keys '+', '-' etc.
> 
> To be finished when I'm back to the office, i.e. in 10 days or so.
> 
> Meanwhile, please, if you're hit by this bug, please try these patches. I am
> not 100% confident that I didn't break something for other keys than the one
> I tested... given that the patches ended up being a lot more intrusive than
> I was initially hoping.

Can we get a mini guide how to apply this patch? I d really like to give it a try.
Comment 46 Tobias Bora 2012-11-15 21:41:13 UTC
Hello !

I agree with Milovan, a mini guide would be quite helpful. Is is always available on kubuntu 12.10 ?

Do you have some news about the integration of this patche in the next kubuntu release ? When is it going to be add in the official KDE version ?

Thanks.
Comment 47 tarnmarlin 2012-12-06 17:46:37 UTC
This is one legendary bug.  It is going to be 4 years old soon. Yet it's also the kind of thing you notice on day one. It just shows no one at KDE really uses their keyboard. It's actually a deal breaker and I keep going back and forth between KDE and GNOME JUST because of this. So many guides talk about how to work around this bug, instead of just fixing it. I can't care about fancy features if I can't even quick tile my windows properly (and using something other than the keypad risks interfering with emacs).

I hope this stupid bug gets fixed. Or I might have to waste my time looking at the source code instead. I don't have enough votes to give to this bug.
Comment 48 Navid Zamani 2012-12-06 18:54:03 UTC
(In reply to comment #47)
I can tell you one thing: It will be fixed in a heartbeat, if xkb is dead.
Apparently it’s a horrible mess and so nobody wants to touch in even with a pitchfork, even after 4 years. I can relate to that.

I hope that xkb goes away. Maybe the kernel gets reworked so X doesn’t have to use its own implementation… or maybe Wayland does it differently…

I for one, consider the concept of a “desktop environment” to be a wrong concept we should never have started, and the “tablet” one to be a step in an even worse direction. Hence I detached myself and am making my own graphical shell for humans with fully working brains that actually want to create something with their computers.
Comment 49 Milan 2013-06-04 22:59:09 UTC
Hi all,

After trying for some time I found a workaround. This works better than mapping the keys to XF86Launch using xmodmap like Pistos proposed. I tried it that way but I also use the numpad a lot for calculations etc so it was a no-go for me.

I found the following workaround using xbindkeys. First you need to install xbindkeys. Then you can map any key combination to a qbus kwin shortcut. You can get a list of all available shortcut names using the following command in the terminal:

qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.shortcutNames

and all window commands by:

qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.shortcutNames | grep Window

You can then use the shortcut name you want and bind the keys to it by modifing ~/.xbindkeysrc

I've added the following to my .xbindkeysrc file:

## begin .xbindkeys

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Bottom Left'"
Control + Alt + KP_1

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Bottom Right'"
Control + Alt + KP_3

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Top Left'"
Control + Alt + KP_7

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Top Right'"
Control + Alt + KP_9

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Left'"
Control + Alt + KP_4

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Right'"
Control + Alt + KP_6

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Minimize'"
Control + Alt + KP_2

## end .xbindkeys

Now my numpad keys in combination with Control+Alt are used for tiling and maximizing windows.

Hope this helps someone!
Comment 50 Milan 2013-06-04 23:02:30 UTC
Forgot to add:

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Maximize'"
Control + Alt + KP_8
Comment 51 Tobias Bora 2013-06-06 19:15:25 UTC
@ Milan : Great !!! It works perfeclty, it is really simple to install, modify, configure, test... As long as it's not officially supported, this solution will be mine !

Thanks !
Comment 52 Milan 2013-06-06 19:23:27 UTC
@Tobias : No problemo :-) If you can't find a specific key or if some combinations don't work you can also use the following command:

xbindkeys -k

This way you can find the keycode, for example c:86 is numpad +

Then just add Control+Alt+c:86 to .xbindkeysrc
I found that sometimes KP_Substract for example won't work, but if I use the keycode instead it does.

Milan
Comment 53 phopedush 2014-01-23 00:02:31 UTC
Coming up on this bug's 5-year anniversary! Woo!
Comment 54 Joachim Jacob 2014-02-05 10:07:58 UTC
Can still confirm the bug. I am in a testing phase, considering switching to KDE. But this is a major bug for me. It does not deserve status 'normal' in terms of usability. KDE's focus seems to be the mouse indeed.
Comment 55 Pistos 2014-02-05 16:39:39 UTC
@Joachim: The workaround I mentioned above has been serving me perfectly.  As such, this is a non issue for me.  Someone else also posted an alternative workaround.  Have you tried either of these?
Comment 56 Joachim Jacob 2014-02-10 10:59:13 UTC
(In reply to comment #55)
> @Joachim: The workaround I mentioned above has been serving me perfectly. 
> As such, this is a non issue for me.  Someone else also posted an
> alternative workaround.  Have you tried either of these?

To show my willingness to help, I have implemented the qbus workaround of Milan. 

Note:
1. definitely use 'xbindkeys -k' to determine the keyboard shortcuts
2. the behaviour of this method seems to be 'switching': pressing numpad 9 again and again switches between previous position and top right tiling. This is not what I intended for.
3. there is no 'quick tile to top' and 'quick tile to bottom' (which I use the most actually).

So yes, thanks for asking, but unfortunately, after 30 minutes of work, it is still an issue for me. Don't ignore it please! :-)
Comment 57 Tobias Bora 2014-02-10 16:24:07 UTC
@Joachim Jacob : It is an other problem. The current behaviour is that if the window is already tiled, it comes back to it's previous position (that's not completely absurd...). I think you'd like that when you press it several times it is more or less near from the screen border ? I don't know if it's possible for the moment (maybe a tiling scripts exists, I saw this one but I'm not sure it's what you want http://kde-look.org/content/show.php/Tiling?content=161151), but you can ask it if someone is interested in making this kind of feature.

About the "quick tile to top/bottom" I was surprised to when I saw it wasn't present, maybe you could do a feature request, I don't think it's really hard to implement.
Comment 58 Vortex 2014-02-23 16:14:21 UTC
This ist extremely annoying, since I use the Numpad excessively. Five years for such a critical bug are unbelievable. PLEASE fix it.
Comment 59 mhoppstaedter 2014-03-07 13:11:23 UTC
I also think that there should be a solution for this bug after such a long time. 
Please fix this. Thank you.
Comment 60 Navid Zamani 2014-03-07 14:01:11 UTC
Actually, it got worse. Now certain keyboard shortcuts do not work anymore at all in some layouts. It’s the same basic bug.

I think KDE needs a complete rewrite of its input system. From scratch. Including the underlying X layer’s part. It’s simply FUBAR.

Maybe as a Google Summer Of Code project?

Otherwise KDE 4 will never come out of beta.
Comment 61 Christoph Feck 2014-03-16 11:18:43 UTC
> Maybe as a Google Summer Of Code project?

If you find a programmer who understands keyboard internals of X11/xkbd, Qt4/xlib, Qt5 /xcb, and kdelibs/khotkeys/kglobalaccel, then please direct him here.
Comment 62 yellowhat46 2015-03-30 20:39:24 UTC
Any news about this bug in plasma 5?
I am on arch linux with KDE 5.8.0 and I have this bug.

Thanks
Comment 63 thorsten 2015-04-24 13:00:54 UTC
Bug still exists in Plasma5 with KDE 5.9.0

Could we at least have it to respond to the numpad? If I set something to Ctrl+1 and during setting it accepts and recognizes this combination why can't it do this later when I use it?
Comment 64 Luis Lezcano Airaldi 2015-04-27 18:26:44 UTC
I think this bug is the same as https://bugs.kde.org/show_bug.cgi?id=346806
Comment 65 Gerard 2015-08-16 23:33:45 UTC
Year 2015. The bug persists.

The shortcuts recorder saves the combination "Control + Alt + KP_6" as "Control + Alt + 6". So you need to use the second shortcut, not the first.
Comment 66 andydecleyre 2016-01-16 15:37:52 UTC
Is kdelibs still the correct product for this bug, or should it be re-associated with a different one, such as plasma-frameworks?
Comment 67 revealed 2016-05-10 10:49:59 UTC
Hello.

I'm facing the very same issue with openSUSE Tumbleweed 20160505. Plasma 5.6.3 ;

My keyboard is of a Logitech MK700 / MK710 pack. Mouse/keyboard combo.

In Plasma i use the model "Logitech / Generic" different models did not change the behaviour.

I wanted to use meta and Numeric Plus Minus for the screenmagnifier. Workaround for me is to enable xbindkeys to autostart as sugguested in comment #49. My $HOME/.xbindkeysrc:
# begin .xbindkeys
"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'view_zoom_out'"
Mod2+Mod4 + Super_L + KP_Subtract
"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'view_zoom_in'"
Mod2+Mod4 + Super_L + KP_Add
## end .xbindkeys

Mod2+ is "Num" (Probably unneccesary).

I was allowed to compare the output of:
xbindkeys -k where the same buttons are working with my machine. The silly is. They produce the very same output. But the one works, and the other not.

Many Thanks.
Comment 68 madumlao 2017-02-06 22:47:53 UTC
Happy 8 years :)
Comment 69 Pistos 2017-02-07 03:22:18 UTC
Happy birthday to you,
Happy birthday to you,
Happy birthday dear
KDE-numpad-bug-that-has-not-been-fixed-in-nearly-a-decaaaaaaade....
... happy birthday to you!
Comment 70 Navid Zamani 2017-02-07 06:13:05 UTC
🎼 Happy crumble dayy … KDEE …
🎼 You are wayy … too buggy for mee …
🎼 Gone to Enlightenment … cause of youu …
🎼 Happy Enlightenment … ’s buggy too. :(
Comment 71 Marcin Kasperski 2017-02-07 07:38:58 UTC
Happy xbindkeys.
Works whatever is desk.

PS What about dropping current keybinding module altogether and just using xbindkeys instead as KDE key-shortcut app (and porting setup module to generating it's config)? I am serious…
Comment 72 Navid Zamani 2017-02-07 08:26:25 UTC
(In reply to Marcin Kasperski from comment #71)

My guess is, that  KDE plans on just moving to Wayland, and dropping X in its entirety. Apparently it was never fun to work with, and isn’t worth it anymore.
So this bug will never be fixed. Ever.

Don’t expect the new stuff to be any less buggy though. It wouldn’t be KDE, if anything would ever leave the early alpha quality level. As always, there will be a lot of settings, but you’re a weirdo if you actually use them and notice that everything breaks, as “everything works fine and is very stable” for the developers, who apparently never use any of them themselves. ;)
(I should create a “Advanced Control Panel” for Gnome 3, with a bazillion settings to play with, that all just cause Gnome 3 to crash. And then I should make big advertisement everywhere about how Gnome 3 is way more configurable than KDE. If KDE then disagrees because they don’t work, I’d tell them “and neither do yours”. … But I won’t … because it would mean learning *gag* Gnome 3. ;)
Comment 73 archsubuser 2017-04-13 12:13:28 UTC
> set quick tile shortcuts to meta+alt+[numkey]
> google for quick tile shortcut bugs for like an hour
> remember to try checking bug tracker
> immediately find this bug report
> be excited that at least quick tiling itself works, and it's actually a problem with numpad input, so I have that going for me, which is nice
> see that bug was reported in 2009
> question hatred for GNOME
> remap quick tile shortcuts to p[]l;',./ like I'm on a stupid %*^#ing netbook
> add to list of reasons to learn C++
Comment 74 Lord Alveric 2017-05-19 18:43:08 UTC
This is a long-standing bug. I'm affected by it too. It is also embarrassing. I know workarounds have been posted over what is nearly a decade...!!!!

My keyboards all have the numeric pad that never sees much use because of this bug. I have 9 virtual desktops, and would only been massively cool if I could simply use this keypad to call them up.

Please, please, PLEASE fix this bug already. I'd do it myself but I have so many projects in the fire right now I don't have the time.
Comment 75 madumlao 2017-05-19 22:57:32 UTC
I have a morbid fascination with watching this bug remain unfixed. There should be Linux user group parties all over the world for the 10 year anniversary. Mark it in your korganizers folks: 2019-02-06, the 10-year kde numpad bug party. Heck invite your GNOME friends along!
Comment 76 Navid Zamani 2017-05-20 00:54:41 UTC
Since this bug has turned into a bulletin board by now…

Frankly, there is no viable desktop environment for Linux nowadays.
• KDE hasn’t left “early beta” quality since 4.0, as this bug shows. Try anything out of the ordinary in the settings, and it will either be broken or not exist anymore. (Kate is still my favorite though.)
• Gnome took it to its logical conclusion, and just removed all the features right away anyway. Including themability. (Qalculate still can’t be beaten though.)
• Ditto for Cinnamon/Mate, which are of better quality, but still crippled by minimalism.
• XFCE et al are even more minimal, so even less viable for non-consumers.
• Enlightenment is currently in a large transition, and also only works if you don’t try anything too much out of the ordinary, if at all.

I think it is time for something new. Something clean and elegant, yet uncompromisingly powerful. A true Linux PC graphical shell. Not a “desktop environment”. Not a command line / search. Yet with all the advantages of both.

Where is it though?
Comment 77 Gerard 2017-05-26 15:36:11 UTC
(In reply to Navid Zamani from comment #76)
> Since this bug has turned into a bulletin board by now…
> 
> Frankly, there is no viable desktop environment for Linux nowadays.
> • KDE hasn’t left “early beta” quality since 4.0, as this bug shows. Try
> anything out of the ordinary in the settings, and it will either be broken
> or not exist anymore. (Kate is still my favorite though.)
> • Gnome took it to its logical conclusion, and just removed all the features
> right away anyway. Including themability. (Qalculate still can’t be beaten
> though.)
> • Ditto for Cinnamon/Mate, which are of better quality, but still crippled
> by minimalism.
> • XFCE et al are even more minimal, so even less viable for non-consumers.
> • Enlightenment is currently in a large transition, and also only works if
> you don’t try anything too much out of the ordinary, if at all.
> 
> I think it is time for something new. Something clean and elegant, yet
> uncompromisingly powerful. A true Linux PC graphical shell. Not a “desktop
> environment”. Not a command line / search. Yet with all the advantages of
> both.
> 
> Where is it though?

Hi, Navid. I loved KDE 4 and I used this temporary solution by binding some shortcuts using xbindkeys. Check my dotfiles: https://github.com/gerardbm/dotfiles/blob/master/.xbindkeysrc

However, KDE 5 (Plasma) is more buggy, so I switched to i3-gaps and I recommend a 'tiling windows manager' more than 'desktop environments'. It's a subjective opinion, of course. 

Windows managers are clean, elegant and they can be configured through dotfiles, so you can save them in a github repository and clone to any machine to use  the same configuration. 

There are some interesting WMs: dwm (configured in C, so you need to compile it every time), awesome (configured in Lua and more extensible), xmonad (configured in haskell), etc. Take a look at Unixporn on Reddit.
Comment 78 Jarno Malmari 2017-05-30 10:24:12 UTC
Thanks for the workaround @Milan! Giving two cents back, here's a Scheme version (.xbindkeysrc.scm):

(map (lambda (binding)
       (xbindkey-function
        (car binding)
        (lambda ()
          (run-command (string-append
                        "qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut '"
                        (cadr binding)
                        "'")))))
     '(((Mod4 KP_Up)    "Window Maximize")
       ((Mod4 KP_Down)  "Window Minimize")
       ((Mod4 KP_Left)  "Window Quick Tile Left")
       ((Mod4 KP_Right) "Window Quick Tile Right")
       ))
Comment 79 David Faure 2017-06-15 08:05:13 UTC
My new laptop has a numeric keypad, so I was actually able to come back to debugging this.

Qt5 supports "Ctrl+Num+1" since Qt 5.1 (which is something that some of you people could have found out, rather than just ranting), we just need to record it that way, and grab that.

See https://phabricator.kde.org/D6226 for a start.
I also have worked on kwindowsystem and kglobalaccel for global accel support, it works, but Ctrl+& doesn't work (implicit shift), I need to find out if it was broken by my changes and how to fix it.
Comment 80 Navid Zamani 2017-06-15 23:12:22 UTC
(In reply to David Faure from comment #79)

Thanks for looking into this.
You must understand,that after 8 years, we simply have given up, and also don’t consider it to be our job. We’ve long switched to something more sensible, and at least I consider KDE dead now. So it’d be a waste of time. (Ranting still feels good though. :P)

Also, I have a layout with three different kinds of shift keys, where this bug disables way more than just certain numpad combinations.
Comment 81 David Faure 2017-06-16 07:30:09 UTC
Git commit 033ad8c63a728904d464a3566ccd71f69ad946ad by David Faure.
Committed on 16/06/2017 at 07:29.
Pushed by dfaure into branch 'master'.

KKeySequenceWidget: make it possible to record Ctrl+Num+1 as a shortcut.

Summary:
Qt supports this string representation for Qt::KeypadModifier since 5.1
but this code didn't support that modifier.

This is the easy part of the fix for the 8-years-old bug, and it makes
it possible to use the numeric keypad for application shortcuts.

The bigger issue is handling of keypad modifiers in global shortcuts
(patches to come for kwindowsystem and kglobalaccel).

Test Plan: Set shortcut Ctrl+Num+1 for "decrement number by 1" action in kate, works.

Reviewers: aacid

Reviewed By: aacid

Subscribers: apol, #frameworks

Tags: #frameworks

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

M  +17   -14   src/kkeysequencewidget.cpp

https://commits.kde.org/kxmlgui/033ad8c63a728904d464a3566ccd71f69ad946ad
Comment 82 David Faure 2017-06-16 07:38:41 UTC
"job" ? Nobody's getting paid here. You, me, everyone else, we're all working *together* on free software. Fixing it is everybody's and nobody's *job*. If you stopped caring about KDE, that's fine, you can unsubscribe from this report. I'm fixing this for the other people who voted for this bug - and who knows, maybe I'll need such a shortcut myself one day.

The fixes are up for review now.
https://phabricator.kde.org/D6233
https://phabricator.kde.org/D6234
Comment 83 Navid Zamani 2017-06-16 15:23:56 UTC
(In reply to David Faure from comment #82)
> "job" ?

You know exactly how I meant it, yet your reaction is so … KDEy…
Not my job does not imply your job. Nor does any of it imply employment or being paid. English “job” is broader than Denglish “Job”.

>  You, me, everyone else, we're all working *together* on free software.

Nope. We’re not in KDE together. My work resources go towards ending the concepts  “Desktop” (and not in favor of mobile OSes either), “Application”, “Button”, etc, forever, in favor of a OS for *computer users* (as opposed to app[lication] users).

</thread>
Comment 84 David Faure 2017-06-18 21:08:36 UTC
*** Bug 357133 has been marked as a duplicate of this bug. ***
Comment 85 David Faure 2017-08-11 06:26:28 UTC
Git commit 32526718eae99ccb594360627586eebdf793372b by David Faure.
Committed on 11/08/2017 at 06:26.
Pushed by dfaure into branch 'master'.

KKeyServer: fix handling of KeypadModifier.

Summary:
This required adding a new method symXModXToKeyQt since
symXToKeyQt (without modifier as input) has no way to find out
whether to use XK_KP_1 or XK_1. For this reason symXToKeyQt is now
deprecated.

Includes a unittest for keyQtToSymX, keyQtToModX and symXModXToKeyQt.

Test Plan:
After porting kglobalaccel to KKeyServer::xcbKeyPressEventToQt,
the following global shortcuts were successfully tested:
Ctrl+1, Ctrl+Num+1, Ctrl+Num+/, Ctrl+F1, Ctrl+& (implicit shift)

Reviewers: graesslin

Subscribers: graesslin, #frameworks

Tags: #frameworks

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

M  +1    -0    autotests/CMakeLists.txt
A  +79   -0    autotests/kkeyserver_x11_unittest.cpp     [License: LGPL (v2/3+eV)]
M  +96   -52   src/platforms/xcb/kkeyserver.cpp
M  +13   -1    src/platforms/xcb/kkeyserver_x11.h

https://commits.kde.org/kwindowsystem/32526718eae99ccb594360627586eebdf793372b
Comment 86 David Faure 2017-08-15 14:17:18 UTC
Git commit 2c20ddff034e4958bf0536ca91ae9e444955305d by David Faure.
Committed on 06/08/2017 at 21:38.
Pushed by dfaure into branch 'master'.

KGlobalAccel: port to KKeyServer's new method symXModXToKeyQt, to fix numpad keys

Test Plan:
the following global shortcuts were successfully tested:
Ctrl+1, Ctrl+Num+1, Ctrl+Num+/, Ctrl+F1, Ctrl+& (implicit shift)

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

M  +7    -45   src/runtime/plugins/xcb/kglobalaccel_x11.cpp

https://commits.kde.org/kglobalaccel/2c20ddff034e4958bf0536ca91ae9e444955305d