Kwin doesn't differentiate Meta+1 and Meta+Num+1 STEPS TO REPRODUCE 1. Try to assign Meta+Num+1 keyboard shortcut to some action in System Settings > Keyboard Shortcuts 2. I'll warn you that there's a conflict with the task manager shortcuts which use Meta+Number OBSERVED RESULT Kwin doesn't differentiate between numpad and non-numpad shortcuts EXPECTED RESULT Kwin should differentiate between numpad and non-numpad shortcuts SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 34 (available in About System) KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88 Qt Version: 5.15.2
Issue is still present on. My custom keyboard shortcuts are broken on wayland sessions. Linux/KDE Plasma: Arch Linux Plasma 5.24.4 KDE Frameworks 5.93.0
Did it do anything different on X11?
(In reply to David Edmundson from comment #2) > Did it do anything different on X11? In my case, I have the numpad with numlock off mapped to the corners of the screen. For example in X11 my keybindings look a bit like this (Numlock off): Meta + Num + 7 would snap a window to the top left Meta + Num + 9 snap top right Meta + Num + 5 max and unmaximize window Meta + Num + 6 Snap to the right Meta + Num + 4 Snap to the left ...and so on. These key combinations would register specifically as Meta + Left, Meta + Right in Wayland
Same bug on plasma 5.27.7. Maybe related bugs: https://bugs.kde.org/show_bug.cgi?id=453423, https://bugs.kde.org/show_bug.cgi?id=471093
Nate, could you add please this bug to 15 minutes bugs list? It's very frustrating that simple keybindings not working as intended in Wayland session.
We aren't counting any Wayland-only issues among the 15-minute bugs at the moment.
Possible dupe of bug 413310
Right you are, thanks! *** This bug has been marked as a duplicate of bug 413310 ***
(In reply to Nate Graham from comment #8) > Right you are, thanks! > > *** This bug has been marked as a duplicate of bug 413310 *** The bug explicitly states that it's encountered in X11 But this particular bug is only encountered in Wayland. The problem seems to be very different on the other ticket (not hotkeys, but some menu items activation) I had to re-assign my shortcuts in order to use wayland session, and I'd love to get to my original shortcuts. It's definitely wayland-specific. Any way you could reconsider making this a duplicate @Nate?
You're right. I'll fix it.
(In reply to Nate Graham from comment #6) > We aren't counting any Wayland-only issues among the 15-minute bugs at the > moment. Is there such small amount of KDE/Wayland users that fixing KDE/Wayland bugs does not make any sense?
We fix Wayland bugs all the time. We simply aren't tracking them in the 15-minute bug initiative until we're recommending Wayland by default.
(In reply to Nate Graham from comment #12) > We fix Wayland bugs all the time. We simply aren't tracking them in the > 15-minute bug initiative until we're recommending Wayland by default. With X11 going more and more into unmaintained area, distros moved to Wayland by default this "until we are recommending Wayland by default" sounds funny. Anyway, I understand that proper handling of keyboard may be low priority. Alphanumeric part works, Fx keys work, cursors work so why bother using rest of keyboard.
It is still present in plasma 6 RC1. Before plasma 6, I didn't use wayland, so I can't say if this bug existed before, but since the first version of plasma 6 I tested (beta 1) I've been struggling with this bug. No alerts are displayed to me, and the shortcut even works in the current section, but after restarting the section or starting a new one, it appears to be changed. When setting the shortcut, it is displayed as "Alt+2": https://i.imgur.com/cKvWw07.png But when restarting it is changed to "Alt+Num+2" and no longer works: https://i.imgur.com/xq4LnQ8.png And when "Alt+Num+2" is registered, it is even possible to create a shortcut for "Alt+2" so that the two are registered at the same time, as if they were really different: https://i.imgur.com/37RRKuD.png
can we change the status of this bug to confirmed to get a little more priority?
So many people reported so it should be CONFIRMED, right?
> And when "Alt+Num+2" is registered, it is even possible to create a shortcut for "Alt+2" so that the two are registered at the same time, as if they were really different: https://i.imgur.com/37RRKuD.png This is how it should be! Read the bug report carefully. They are different keys, after all (the regular numbers above qwerty part vs. the numpad; same applies to ins-del-home-end-pgup-pgdwn block & cursor keys vs. the numpad when numlock is OFF). I can see users elsewhere who have conflicting desires. Some wish to set only one shortcut and have it triggered from both keys. IMHO those people should just set two shortcuts. In any case, this is inconsistent when comparing to X.Org sessions (where the keys are interpreted properly as separate, different keys).
> This is how it should be! Read the bug report carefully. They are different keys, after all (the regular numbers above qwerty part vs. the numpad; same applies to ins-del-home-end-pgup-pgdwn block & cursor keys vs. the numpad when numlock is OFF) none of these shortcuts work for me. is that how it should be?
(In reply to Podagric from comment #18) > > This is how it should be! Read the bug report carefully. They are different keys, after all (the regular numbers above qwerty part vs. the numpad; same applies to ins-del-home-end-pgup-pgdwn block & cursor keys vs. the numpad when numlock is OFF) > > none of these shortcuts work for me. is that how it should be? On the shortcut editor (testing on Plasma 6 Wayland), there is currently no distinction between Numpad keys and standard keys - with Num Lock off, pressing 7 will be the same thing as pressing Home, and with Num Lock on - no shortcut will be registered because the shortcut manager will not let you register shortcut to standard QWERTY keys (which number row keys are part of and Numpad keys are mapped identically). As far as I can tell this is a Qt deficiency. My specific concern was that in other kind of keyboard shortcut triggering - specifically menu accelerators - Numpad keys are completely ignored even when the respective non-numpad key is functioning properly as a menu accelerator. So this is fscked up both ways.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5032
(In reply to Bug Janitor Service from comment #20) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/kwin/-/merge_requests/5032 This fixes the global shortcut functionality in kwin. https://codereview.qt-project.org/c/qt/qtwayland/+/533675 is needed for recording the key sequence in the KCM to work
Git commit 296d3f31be9f7148c4296a284d9c76271c6ed5bd by Vlad Zahorodnii, on behalf of Nicolas Fella. Committed on 24/01/2024 at 14:20. Pushed by vladz into branch 'master'. Consider Qt::KeypadModifier relevant for global shortcuts Otherwise kglobalaccel can't distinguish between numbers on the num block and other numbers Related: bug 453423 M +3 -0 src/xkb.cpp https://invent.kde.org/plasma/kwin/-/commit/296d3f31be9f7148c4296a284d9c76271c6ed5bd
Git commit ae23df1f53e27229cb9d385a9dadfc8e2bc9ef08 by Vlad Zahorodnii, on behalf of Nicolas Fella. Committed on 24/01/2024 at 14:26. Pushed by vladz into branch 'Plasma/6.0'. Consider Qt::KeypadModifier relevant for global shortcuts Otherwise kglobalaccel can't distinguish between numbers on the num block and other numbers Related: bug 453423 (cherry picked from commit 296d3f31be9f7148c4296a284d9c76271c6ed5bd) M +3 -0 src/xkb.cpp https://invent.kde.org/plasma/kwin/-/commit/ae23df1f53e27229cb9d385a9dadfc8e2bc9ef08
With current build from Neon testing (4:5.91.90+p22.04+vstable+git20240128.0255-0) - which to the best of my understanding includes the patches that resolved this issue - numpad keys, with Num Lock turned on, indeed do not conflict with the main keyboard number keys. That being said - they now produce the cursor control symbols (arrows, home/end/ins/del, etc) regardless of the state of Num Lock, and as a result the shortcut configuration cannot distinguish between Home and numpad 1 or Insert and numpad 0. This has (kind of) the same implications as not differentiating between number keys and numpad keys (when Num Lock is on) - they cannot be used to set up different shortcuts. The situation is definitely better, in that the shortcut behavior of numpad keys is no longer dependent on the state of Num Lock - but I think what everyone was hoping is that when you program a shortcut with the wide key at the bottom of the shortcut , it would show up as something like "KP Insert" (at least that's what GTK is calling it) and I can also program a different shortcut set with the "real" Insert key.
Oded: thanks for testing! So it looks like it came from bad to bad. Just other bad than it was before.
https://codereview.qt-project.org/c/qt/qtwayland/+/533675 is not merged, which is needed for Qt applications to correctly process the keys
Thanks Nicolas. Will wait for it then.
Nicolas: that's Qt6 change. What about Qt5 which is still in use in KDE?
(In reply to Marcin Juszkiewicz from comment #28) > Nicolas: that's Qt6 change. What about Qt5 which is still in use in KDE? Maybe it can be backported to the KDE patch collection
Qt6-wayland patch landed: https://github.com/qt/qtwayland/commit/e0796865151b06dddc5c5665f9ca8bdc8021fcd8
I just got Qt 6.6.2 build 86 from yesterday (on neon: 6.6.2-0xneon+22.04+jammy+stable+build86) - should that include the Qt6 patch? If so I still can't get the shortcuts KCM to understand the difference between META+1 and META+Numpad 1.
The patch will be part of Qt 6.6.3