| Summary: | 'Numlock' is not trigger-able | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kglobalaccel | Reporter: | Emil Sedgh <emilsedgh> |
| Component: | general | Assignee: | Martin Flöser <mgraesslin> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | kdelibs-bugs, thomas.luebking |
| Priority: | NOR | Flags: | thomas.luebking:
corner_case+
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Emil Sedgh
2015-08-11 19:53:24 UTC
I assume it works with no shortcut (whether for kwin, plasmashell, krunner, ...)? Stunningly, it works here (numlock is actually a modifier on the X11 level, like meta or alt) I assme the problem is a keyboard layout change after kglobalaccel was started. Try to pkill kglobalaccel5; sleep 2; kglobalaccel5 & and whether the numlock shortcut suddenly works afterwards. Oh well, I'm using Caps-Lock as an additional 'Numlock'. But I assumed that works fine because on 'Set shorctur' dialog when I press the Caps Lock button, it catches 'NumLock'. So steps to reproduce: 1) Go to system settings -> Input devices -> Keyboard -> Advances tab 2) Under the menu 'Caps lock key behavior' check the 'Mark Caps Lock an additional Num Lock' 3) Open 'Global shortcut settings'. 4) Choose an action (Like 'Activate Present windows on all desktops') 5) Click to define a custom shortcut 6) Press 'Caps lock' (you can see that buttons shows 'Numlock') 7) Apply the changes 8) Press 'Numlock' (And no, restarting kglobalaccel didn't help) To clarify, you assign SW "numlock" by pressing HW "caps lock" and then the shortcut fails on the HW "numlock" key? Oh I'm sorry Thomas, no. Step 8 must be 'Press Caps Lock' What happens here is that only one of the keys (caps_lock XOR numlock) a) acts as numlock (toggling the state) b) triggers the shortcut despite both generate a Num_Lock keysym. It seems to be always the same and -actually- rather caps lock (ie. numlock being dead, but that might depend on the hardware layout or some caching) How did that act on KDE4? Could you use both keys to toggle the keypad state? Can you use _one_ of the keys to trigger the shortcut? I don't have an actual Numlock key on my keyboard (Rather Syslock+Scroll Lock acts as NumLock). But on KDE4, I could've used Capselock-as-Numlock alone (with no combination). I also could've used Caps Lock alone. Im also on #kwin if you need me. I would assume that's because xcb_key_symbols_get_keycode returns a list of keycodes, but kglobalaccel only interprets the first one. I could assume unlike Xlib, where XKeysymToKeycode returns only one value, the keycodes are handled distinct in xcb. Martin, recall https://git.reviewboard.kde.org/r/122454/#review75534 ;-) dev note: the returned array is nullptr or terminated by XCB_NO_SYMBOL https://git.reviewboard.kde.org/r/124710/ Notice that you can map caps_lock to other stuff (notably using xmodmap allows for pretty much everything in a rather simple manor) Freaking around with numlock is generally error prone since you toggle the modifier as well and the modifier combo *does* matter on X11. While th major toolkits will likely cover that, other handcrafted code may fail to handle certain keyboard input correctly. I applied the patch and tested it, but it doesn't seem to fix the issue. That would seem to be a problem. However, there's a trap on installation. Plugins by default get installed to /usr/lib/plugins/org.kde.kglobalaccel5.platforms but most distro installation have a plugin path of /usr/lib/qt/plugins/org.kde.kglobalaccel5.platforms => check whether the updated plugin is loaded (watch make install and compare "strace kglobalaccel5 2>&1 | grep KF5GlobalAccelPrivateXcb.so") Since you however luckily can build patches, we can easily add some debug code to see what's failing otherwise. I have KF5/Plasma built from sources using kdesrc-build, so there's no system-wide KDE installed. So I'm sure this is the used plugin. However, something funny just happened. I saw you last comment and found out that there's now a 'kglobalaccel5' binary. `killall kglobalaccel5` `kglobalaccel5` Voila. The caps:num now works as expected :) I tried a few times. Started Plasma, it was broken. Then I killed kglobalaccel5 and started it manually and caps:num works. That's with your patch applied. I will now try to undo your patch and see if it still behaves the same when killed and started manually. I removed your patch and tried again. Even without your patch, killing kglobalaccel5 and starting it again fixes the issue. Errheeemmm... I'll refer to comment #1, push out my chest and say: "I told you!" (Silence, I need that ;-) Did you fetch kglobalaccel from git (master) or a stable tarball - for the recent commits seem to have patches for keymap change updates? Oh you indeed told me and I promise I tried that. Weird. Sorry about that man. Its from git. Last commit: "Upgrade KF5 version to 5.14.0." No problem. Just helps telling myself that I'm a genius ;-) So this is rather "just" a defect in catching re-map events then. *** This bug has been marked as a duplicate of bug 350816 *** Git commit bf71e536bd14e954c44da4ed7af43ef4ee711953 by Thomas Lübking. Committed on 05/10/2015 at 21:19. Pushed by luebking into branch 'master'. Grab all keys for a symbol Otherwise, if a symbol is represented by more than one key, only one key will be an operative shortcut (though they're both the same symbol) REVIEW: 124710 M +63 -58 src/runtime/plugins/xcb/kglobalaccel_x11.cpp http://commits.kde.org/kglobalaccel/bf71e536bd14e954c44da4ed7af43ef4ee711953 Just wanted to thank you, Thomas :) The actual bug (kbd map updates not caught) is not fixed, the patch only improves the situation for multiple mappings. *** Bug 367953 has been marked as a duplicate of this bug. *** |