SUMMARY Can't blank screen with hotkey meta+k. STEPS TO REPRODUCE 1. configure a hotkey (meta+k) to blank screen (xrandr script, powerdevil, dbus, ...) 2. press the hotkey untill and release it after some time (the problem i evident when you release the key when the screen is already powering off) OBSERVED RESULT As soon as you press the key the monitor powers off. When you release the keys on the keyboard the release event wakes up the screen again. EXPECTED RESULT There are two valit behaviors: 1) When you release the keys on the keyboard the keyboard-release-event wakes off the screen (not the key-press-event). 2) (in this case the bug should be assigned to powerdevil) a keyboard realease event should never wake up the screen. SOFTWARE/OS VERSIONS Operating System: Kubuntu 19.10 KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.67.0 Qt Version: 5.12.4 Kernel Version: 5.3.0-48-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 15,1 GiB of RAM ADDITIONAL INFORMATION Would be nice to have the option to configure an action to be fired on on keyboard-release-events.
Cannot reproduce; If I hit Meta+L to lock the screen, for example, it locks on press, not release. What is your use cases? I'm having a hard time understanding what the problem is.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Meta+l works for me too. Did you reproduce exactly as reported? I.e. add a new (e.g. Meta+k) shortcut from the systemsettings gui to trigger an action (e.g. xrandr dpms force off). Is this working for you? Are you on my same version?
*** Bug 459384 has been marked as a duplicate of this bug. ***
POSSIBLE IMPLEMENTATION P_BUFFER - buffer of pressed keys S_BUFFER - buffer of suspended keys 1. Accumulate pressed keys in P_BUFFER 1.1 on keypress event add pressed key to P_BUFFER (works same for all buttons, so we would be able to start shortcut from any shortcut's keys) 2. on keyrelease event of any key contained in P_BUFFER, fire shortcut with all keys currently in P_BUFFER, including one that was released just before (that is because we won't delete it from P_BUFFER just after the key was released, but will wait for shortcut to fire and only then remove) Note: other (still pressed) keys are moved to suspending buffer S_BUFFER. That means that when other keys will be released they won't cause any undesired shortcuts. BUT when any new key is pressed, already pressed keys (i.e. contained in S_BUFFER) will be moved back to P_BUFFER. Key will be REMOVED (and not moved) from suspending buffer ONLY when released EXAMPLE Lets imagine that we have next shortcuts defined: ctrl + shift - switch keyboard layout ctrl + shift + t - open new terminal instance ctrl + shift + d - show desktop And user acts like this: "wants to show desktop and open terminal" 1. press "shift" 2. press "ctrl" 3. press "d" and release it (ctrl + shift are still pressed) 4. press "t" and release ctrl, shift, t in order 5. press ctrl, shift to switch keyboard layout 6. releases shift What happens according to the algorithm: 1. shift is added to P_BUFFER 2. ctrl is added to P_BUFFER 3. d is added to P_BUFFER 4. release event for "d" received 5. shortcut "show desktop" is fired 6. content of P_BUFFER is moved to S_BUFFER (i.e. ctrl, shift, d) 7. system detects that "d" is no longer pressed and removes it from S_BUFFER (so the content of S_BUFFER becomes "ctrl, shift") 8. press event for "t" received 9. ctrl, shift are moved back to P_BUFFER 10. "t" is added to P_BUFFER 11. "ctrl" release event received 12. open new terminal instance shortcut fired 13. content of P_BUFFER is moved to S_BUFFER (i.e. ctrl, shift, t) 14. system detects that "ctrl" is no longer pressed and removes it from S_BUFFER (so the content of S_BUFFER becomes "shift, t") 15. receives release events for "shift, t" 16. removes "shift, t" from S_BUFFER so it becomes empty 17. receives press events for "ctrl" and "shift" 18. adds them to the P_BUFFER 19. receives release event for "shift" 20. fire "switch keyboard layout" shortcut
*** Bug 476353 has been marked as a duplicate of this bug. ***
I've tested Andrey suggestion from https://bugs.kde.org/show_bug.cgi?id=453506#c3 Since Plasma 5.8 we can bind "Modifier-only" KWin shortcut (for now it could be "Meta", "Alt", "Shift" and "Control", according to the https://invent.kde.org/plasma/kwin/-/blob/Plasma/5.27/autotests/integration/modifier_only_shortcut_test.cpp) which triggers action on release (not press). So I assigned "Shift" to the qdbus command to switch the keyboard layout kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift' 'org.kde.keyboard,/Layouts,org.kde.KeyboardLayouts,switchToNextLayout' qdbus org.kde.KWin /KWin reconfigure Looks like this is the way! Now I can switch keyboard layouts with a single "Shift" press. But when I use combinations involving "Shift", the keyboard layout doesn't change and combinations seem to work properly. E.g., I can type capital letters and other symbols, use Ctrl+Shift+V paste on a terminal emulator, etc.
(In reply to Yevhen from comment #7) > I've tested Andrey suggestion from > https://bugs.kde.org/show_bug.cgi?id=453506#c3 > Since Plasma 5.8 we can bind "Modifier-only" KWin shortcut (for now it could > be "Meta", "Alt", "Shift" and "Control", according to the > https://invent.kde.org/plasma/kwin/-/blob/Plasma/5.27/autotests/integration/ > modifier_only_shortcut_test.cpp) which triggers action on release (not > press). > So I assigned "Shift" to the qdbus command to switch the keyboard layout > > kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift' > 'org.kde.keyboard,/Layouts,org.kde.KeyboardLayouts,switchToNextLayout' > qdbus org.kde.KWin /KWin reconfigure > > Looks like this is the way! Now I can switch keyboard layouts with a single > "Shift" press. But when I use combinations involving "Shift", the keyboard > layout doesn't change and combinations seem to work properly. E.g., I can > type capital letters and other symbols, use Ctrl+Shift+V paste on a terminal > emulator, etc. P.S. qbbus method call for "Alternative shortcut" (which supports "OSD on layout change" on both Wayland and X11) works as well: kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift' 'org.kde.kglobalaccel,/component/KDE_Keyboard_Layout_Switcher,org.kde.kglobalaccel.Component,invokeShortcut,Switch to Next Keyboard Layout' qdbus org.kde.KWin /KWin reconfigure
Could someone help clarify what this bug report is about? I don't think I understand what is reported/requested here after reading all the comments. Normal shortcuts trigger on press, and we are not going to change that. If the bug report is about that, this should be closed as INTENTIONAL. Modifier-only shortcuts trigger on release. Modifier-only shortcuts assigned through system settings (not through kwin) is fixed by https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/44. Is there anything left to be done here?
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!