Bug 453423 - Numpad shortcuts don't work in wayland sessions.
Summary: Numpad shortcuts don't work in wayland sessions.
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kglobalaccel
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.108.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: John Brooks
URL:
Keywords: wayland
: 471093 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-05-05 14:40 UTC by krypek
Modified: 2024-01-24 13:31 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In: Plasma 6.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description krypek 2022-05-05 14:40:14 UTC
STEPS TO REPRODUCE
1.  Make sure your on a wayland session
2.  Open KDE System Settings (systemsettings)
3.  Go to Shortcuts/Shortcuts/Media Controller/
4.  Try to assign a shortcut to any numpad key

OBSERVED RESULT
It cannot be assigned.
It can be assigned and it works in an X11 session.

EXPECTED RESULT
You should be able to assign exclusive numpad keys in wayland sessions.
And they should be working, just like in X11 sessions.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.17.5-arch1-1 (64-bit)
KDE Plasma Version:  5.24.5
KDE Frameworks Version: 5.93.0 
Qt Version: 5.15.3
Graphics Platform: Wayland (!!!)

ADDITIONAL INFORMATION
Using English (US) keyboard layout
Comment 1 hueponik 2022-07-05 05:16:18 UTC
I can confirm this bug. 
Numpad numbers (KP1-KP9) are seen same as just number on keyboard (1-9), which are mapped to totally different functions.
It's also just ignoring some keys like `KP_Divide` (/) or `KP_Subtract` Numpad (-) when assigning them in combination with Ctrl+Alt
It's not possible to use them as a shortcut (i.e. Ctrl+Alt+KP_Divide is not working)
Comment 2 Anton Skorokhod 2022-07-06 06:37:39 UTC
also confirming this issue on KDE Neon, Plasma 5.25.2, kde frameworks 5.95.0
with X11 session everything works, on Wayland it's impossible to use numpad as separate keys in any keyboard layout (tried US, CZ and RU)
it's not "one layout issue" as I have more layouts configured in system
Comment 3 Marcin Juszkiewicz 2022-09-19 07:33:24 UTC
Same on Fedora 37.

In X11 session I have Meta+4 == switch to 4th desktop and Meta+Num4 to be "move window to left side of screen". I am getting tired of seeing 4th desktop again ;D
Comment 4 Anton Skorokhod 2022-10-28 10:44:26 UTC
kde frameworks 5.99 and 5.26.2, problem still exists
Comment 5 Patrick Silva 2022-10-29 22:49:02 UTC
Cannot reproduce on Arch Linux. I can set ctrl+1 and ctrl+2, for example, and they work.
I use brazilian portuguese (abnt2) keyboard layout.
Comment 6 Anton Skorokhod 2022-10-29 22:53:57 UTC
(In reply to Patrick Silva from comment #5)
> Cannot reproduce on Arch Linux. I can set ctrl+1 and ctrl+2, for example,
> and they work.
> I use brazilian portuguese (abnt2) keyboard layout.

It's not about ctrl+1 or ctrl+2, but about different mapping of ctrl+1 on numbers above leteters and ctrl+1 when "1" is pressed on additional numeric keyboard. On X11 it works (it's different) but on Wayland that "1" is the same on basic and additional part of keyboard :(
Comment 7 Ville Aakko 2022-11-30 19:11:05 UTC
Can confirm this bug on Arch Linux, too.

KDE Plasma can not tell the difference between number pad keys and their normal variants. This includes the numbers when NumLock is on but also PgUp, PgDown, Home, End etc. available when NumLock is off..
Comment 8 Marcin Juszkiewicz 2023-01-10 10:50:08 UTC
wev says:

[14:     wl_keyboard] key: serial: 2056; time: 820672; key: 10; state: 1 (pressed)
                      sym: 1            (49), utf8: '1'
[14:     wl_keyboard] key: serial: 2057; time: 820784; key: 10; state: 0 (released)
                      sym: 1            (49), utf8: ''
[14:     wl_keyboard] key: serial: 2058; time: 822544; key: 87; state: 1 (pressed)
                      sym: KP_1         (65457), utf8: '1'
[14:     wl_keyboard] key: serial: 2059; time: 822632; key: 87; state: 0 (released)
                      sym: KP_1         (65457), utf8: ''

So for Wayland those are two separate keys as they should be. Why KDE thinks otherwise?

And when bug gets closed as WONTFIX?
Comment 9 Marcin Juszkiewicz 2023-04-29 21:12:49 UTC
Updated to Fedora 38 and checked. Bug still applies.

KDE Framework: 5.104.0
KDE Plasma: 5.27.4
Qt: 5.15.9
Comment 10 onlybugreports 2023-05-30 17:24:47 UTC
(In reply to Marcin Juszkiewicz from comment #8)
> wev says:
> 
> [14:     wl_keyboard] key: serial: 2056; time: 820672; key: 10; state: 1
> (pressed)
>                       sym: 1            (49), utf8: '1'
> [14:     wl_keyboard] key: serial: 2057; time: 820784; key: 10; state: 0
> (released)
>                       sym: 1            (49), utf8: ''
> [14:     wl_keyboard] key: serial: 2058; time: 822544; key: 87; state: 1
> (pressed)
>                       sym: KP_1         (65457), utf8: '1'
> [14:     wl_keyboard] key: serial: 2059; time: 822632; key: 87; state: 0
> (released)
>                       sym: KP_1         (65457), utf8: ''
> 
> So for Wayland those are two separate keys as they should be. Why KDE thinks
> otherwise?
> 
> And when bug gets closed as WONTFIX?

I've got the same result. xev and wev reports different keys for '1' and 'KP_1' and the other keypad keys. On KDE x11 I can bind different shortcuts for '1' and 'KP_1' no problem, but under KDE wayland when I press 'KP_1' it acts as if I pressed '1'.

This bug prevents me from using kde wayland since I have several shortcuts mapped to all the keypad keys which really speed up my workflow.

I can'þ compile plasma with KF6 due to work, but would be nice to confirm if this bug still happens considering the migration to QT6.
Comment 11 Tobias Klaus 2023-06-17 11:00:30 UTC
Reproducible on gentoo with:
KDE Framework: 5.106.0
KDE Plasma: 5.27.5
Qt: 5.15.9
Comment 12 Nate Graham 2023-08-07 18:49:41 UTC
*** Bug 471093 has been marked as a duplicate of this bug. ***
Comment 13 Marcin Juszkiewicz 2023-09-30 09:37:25 UTC
I can offer 50€ as kind of bug bounty. Should cover cost of pc105 keyboard as it looks that KDE developers only use laptops or small keyboards without numpad part.
Comment 14 rkeating 2023-10-04 14:44:16 UTC
Can confirm this bug also happens on Kubuntu 23.04 KDE Plasma Version 5.27.8
Comment 15 aplatypus 2023-10-11 11:28:30 UTC
This bug is still present in:

KDE Framework: 5.104.0
KDE Plasma: 5.27.4
Qt: 5.15.9
Comment 16 Kyle B. 2023-11-03 01:04:57 UTC
Confirming this bug is still present on OpenSUSE Tumbleweed 20231031
NumLock is turned ON.

Operating System: openSUSE Tumbleweed 20231031
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.111.0
Qt Version: 5.15.11
Kernel Version: 6.5.9-1-default (64-bit)
Graphics Platform: Wayland

Keyboard: Corsair Strife RGB (104-key standard ANSI layout)
KDE Keyboard model: Generic | Generic 104-key PC

Keyboard Layout: English (US); English (US, intl., with dead keys)
(Neither fix this issue)

This does not happen on X11.

Within KDE shortcuts under system settings, pre-existing shortcuts involving the number pad appear like the following examples:
"Ctrl+Num+5"
"Alt+Num+5"
"Meta+Num+0"

I wonder if "Num" is being considered as a separate, non-existent key?
To test this, I tried using the NumLock key in a shortcut assignment. It actually reads as "numlock" and terminates the sequence.
I'm unable to get "Num" as a registered sequence step.
Comment 17 Kyle B. 2023-11-12 00:34:32 UTC
Possible duplicate of :

https://bugs.kde.org/show_bug.cgi?id=413310
https://bugs.kde.org/show_bug.cgi?id=446389
https://bugs.kde.org/show_bug.cgi?id=461291

These all describe the same problem.

According to the latest comment on 413310 this appears to be a bug in QT specifically.

That bug here claims to be "RESOLVED UPSTREAM", but I do not believe this to be the case.

The QT bug pages are both not listed as resolved at the time of this posting.

https://bugreports.qt.io/browse/QTBUG-57661

https://bugreports.qt.io/browse/QTBUG-94892
Comment 18 Antti Savolainen 2023-11-12 00:51:40 UTC
Also the keybinds work like normal on X11.
Comment 19 Ville Aakko 2023-11-15 15:52:09 UTC
(In reply to Kyle B. from comment #17)

None of them are duplicates. At least bug #446389 is not!

First, considering the original report of this bug (as in: Numpad keyboard shortcuts can not be assigned in Wayland) this report should be closed as FIXED, as the keyboard shortcuts can be assigned, indeed. 

HOWEVER, many (me included) have commented on this bug report previously that KDE Plasma can not *differentiate* between normal keys (i.e. non-numpad keys, including PgUp, Home, End, cursor and the top number row above tenkeyless-part of a keyboard) and Numpad keys when running Plasma, when making shortcuts; meanwhile, running KDE Plasma under X.Org, it can can. Also, the OP mentions the keyword "exclusive" later on, which kind of hints he may have seen this misrecognition problem, too?

I'm certain I've meant to comment in Bug #446389 previously, but commented here instead - possibly because of having too many tabs open and mixing which tab I had open ;-).

#461291 seems to talk about Dolphin. #413310 seems to be a user wanting the OPPOSITE behavior than many other users. The duplicate keys found on the keyboard are recognized by the OS and are different on all keyboards, and alternative keyboard shortcuts exists for a reason (so, I would categorize that bug report as PEBCAK, as fixing it would break other users setups).

I suggest closing this as FIXED as it indeed "works" as Antti pointed out (but not as many expect as per bug #446389).
Comment 20 Marcin Juszkiewicz 2023-11-15 16:18:21 UTC
@Ville Aakko: to be honest I do not care which bugs will be closed and which left open as long as KDE/Wayland will recognize Meta+KP_4 and allow to use it as a shortcut.

https://bugreports.qt.io/browse/QTBUG-94892 is another one about the same.
Comment 21 Bug Janitor Service 2024-01-24 00:52:20 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5032
Comment 22 Nicolas Fella 2024-01-24 01:09:21 UTC
(In reply to Bug Janitor Service from comment #21)
> 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
Comment 23 Vlad Zahorodnii 2024-01-24 13:24:38 UTC
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 446389

M  +3    -0    src/xkb.cpp

https://invent.kde.org/plasma/kwin/-/commit/296d3f31be9f7148c4296a284d9c76271c6ed5bd
Comment 24 Vlad Zahorodnii 2024-01-24 13:29:11 UTC
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 446389
(cherry picked from commit 296d3f31be9f7148c4296a284d9c76271c6ed5bd)

M  +3    -0    src/xkb.cpp

https://invent.kde.org/plasma/kwin/-/commit/ae23df1f53e27229cb9d385a9dadfc8e2bc9ef08