After a while working on my laptop and/or after some suspend/hibernate the super (meta) key stop working in order to launch the application menu. The problem disappear after rebooting. The Alt+F1 shortcut keeps working normally too. Reproducible: sometimes after suspend/hibernate on KDE Plasma 5.11 in Tumbleweed snapshot 21/01/2018 or plugin external USB keyboard. The problem does not happen on KDE Plasma 5.8 LTS. Workaround: I load the application Superkey if I want to work around the problem without rebooting. Rebooting always solves the problem for a while. Note: Launching ksuperkey while Meta key is working fine out-of-the-box after rebooting causes the Meta key to stop opening the application menu. The problem may be related to https://www.reddit.com/r/kde/comments/5ovjqu/super_key_meta_not_working_anymore/ but solutions didn't work. Also trying the command "kquitapp5 kglobalaccel5;kglobalaccel5 & kwin_x11 --replace" didn't work. Same bug/issue in: https://bugzilla.opensuse.org/show_bug.cgi?id=1083562 Probably related issue in: https://bugs.kde.org/show_bug.cgi?id=375000
I have updated my openSUSE Tumbleweed and the problem has happened once too. KDE Plasma: 5.12.2 Qt Version: 5.10 Frameworks Version: 5.43.0 XOrg: Mesa 18.0.0 and xorg-x11-server 1.19.6 Kernel: 4.15.7 Distro: openSUSE Tumbleweed -- Reproducible: - Last time it happened after I folded my 2-in-1 laptop into tablet mode. The keyboad is disabled automatically in tablet mode. Then, after I unfolded my laptop, keyboard was activated again normally but the superkey was not opening the Menu. I didn't try to reboot my system and reproduce this, since I'm still working and I cannot close my applications until finishing my job. --- Workaround: - I run ksuperkey.
After installing of Gnome-Pie app (maybe just coincidence) - Kickoff stops launching with Meta key Plasma: 5.12.3 Apps: 17.12.3 Frameworks: 5.44.0 Qt: 5.10.1 Kernel: 4.14.27-1-MANJARO OS: Netrunner Rolling
Also reproducible on openSUSE Leap 15 KDE Plasma: 5.12.5 Qt Version: 5.9.4 Frameworks Version: 5.45.0 XOrg: Mesa 18.0.2 and xorg-x11-server 1.19.6 Kernel: 4.14.56 -- Reproducible: - Always: After unfolding my 2-in-1 laptop from its tablet mode (completely flipped) into laptop mode again. Also note that keyboard and touchpad are disabled automatically on tablet mode. -- Workaround: I use ksuperkey
Created attachment 114168 [details] Hardware Information
I experience exactly this problem. The biggest difference with what others commented is that I'm using a desktop computer (it's never suspended or hibernated), so maybe we can rule that out. Some context: - ksuperkey is not running (and it never been, AFAIK) - System settings --> Shortcuts --> Global Shortcuts --> Plasma --> Activate Application Menu Widget is set to Alt+F1 - Alt+F1 actually works! System context: - Operating System: KDE neon 5.14 - KDE Plasma Version: 5.14.3 - Qt Version: 5.11.2 - KDE Frameworks Version: 5.52.0 - Kernel Version: 4.15.0-39-generic - OS Type: 64-bit - Processors: 6 × AMD FX(tm)-6100 Six-Core Processor - Memory: 7.8 GiB of RAM
If this happens again, please issue this dbus command: qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.activateLauncherMenu If it shows the application launcher, the bug is in kwin. If it does not, the bug is in plasmashell.
Were you able to test comment #6?
Oops, I totally missed comment 6. But I'm aware of it now. Next time it happens, I'll issue the command and we'll see. Thanks!
*** Bug 405715 has been marked as a duplicate of this bug. ***
(In reply to Christoph Feck from comment #6) > If this happens again, please issue this dbus command: > > qdbus org.kde.plasmashell /PlasmaShell > org.kde.PlasmaShell.activateLauncherMenu > > If it shows the application launcher, the bug is in kwin. If it does not, > the bug is in plasmashell. The bug is in plasma shell. I've opened the lid of my laptop and the kicker bug was there. I ran the command in terminal and kicker started up.
um, I meant the bug must be in kwin
Thanks for the confirmation; moving to KWin. KWin runs the same DBus command to open Kicker/Kickoff, so the bug is in KWin stopping to recognize the Meta key.
I think this may be related. kwin 5.15.4 (x11) Steps to reproduce (a bit silly): 1. Download Dos Navigator 1.51 Freeware Release for MS-DOS from https://www.ritlabs.com/en/products/dn/ (you can also try a different DOS program) 2. Unzip it into a NEW directory 3. Run "dosbox DN.COM" 4. Click inside Dosbox window to grab mouse (press Ctrl+F10 to release grab) 5. Press Alt+X, type "exit" to quit DN and Dosbox 6. Now the Meta (Win) key assigned to Plasma Application Launcher does not work Workaround: "kwin --replace" command fixes the problem.
I also see this bug a couple of times a month, the super key stops responding and I have to restart kwin to get it working again.
Appears to still be present in: Operating System: Kubuntu 19.10 KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.4 Kernel Version: 5.3.0-40-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz Memory: 7.7 GiB of RAM
Appears to still be present in: Operating System: Manjaro KDE KDE Plasma Version: 5.18.3 Processors: 2 × Intel® Core™ i5-7 Memory: 7.7 GiB of RAM
As per indicated in comment 6, this is confirmated to be an issue in kwin.
Appears to still be present in: Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version 5.12.8 Kernel Version: 5.4.0-31-generic
*** Bug 423325 has been marked as a duplicate of this bug. ***
*** Bug 420678 has been marked as a duplicate of this bug. ***
*** Bug 400096 has been marked as a duplicate of this bug. ***
This has been annoying me to no end for the longest time, through multiple fresh installs. Figured this would be fixed at some point as it seems like a relatively high priority issue. But over 2.5 years later it seems no one can figure out the cause? This issue is hands down one of my biggest peeves with KDE, without any permanent workaround that I've been able to find. So I thought I'd just give this a bump to see if anyone has any kind of update or workaround yet?
I know, I know, it drives me crazy too. Thankfully there are semi-easy-ish workarounds: 1. Add the follpoing to kwinrc: [ModifierOnlyShortcuts] Meta=org.kde.plasmashell,/PlasmaShell,org.kde.PlasmaShell,activateLauncherMenu 2. restart KWin But yeah, these shouldn't be needed. :( I'd fix it if I could figure out what the problem was.
Well, glad I'm not the only one :) The workaround worked temporarily, but the issue happened again after restarting. Seems like you had a similar experience per your comments in bug #423325. I'm currently trying out ksuperkey with this in kwinrc instead: [ModifierOnlyShortcuts] Meta= Seems to be working well so far, but I haven't tested it extensively. Of course still not as good as the real thing though.
Happened to me with kubuntu 20.10
Happens every day after 4-5 hours of startup, kubuntu 20.10.
This is the very high queue without a lot of activity. Ultimately this is waiting on someone to come up with some concrete steps to reproduce. If someone does that and I can reliably reproduce I personally promise to work non-stop on a fix - but we can't do much till then.
Is it okay if I grab you the next time I encounter it? I've added [ModifierOnlyShortcuts] Meta=org.kde.plasmashell,/PlasmaShell,org.kde.PlasmaShell,activateLauncherMenu to my kwinrc file, which has made the issue go away seemingly permanently. I'll remove it now and see if it happens again.
KWin stops working when I close my laptop lid. My power options are set to "do nothing". When I open the lid, the meta key has lost its binding. I started my pc and opened a terninal. I entered echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope gdb -pid $(pidof kwin_x11) -batch -ex "set logging file kwin.gdb" -ex "set logging on" -ex "continue" -ex "thread apply all backtrace" -ex "quit" and closed the lid. The meta key lost its binding. Then I opened another terminal and entered win_x11 --replace & disown to restore functionality. Below is the stacktrace from kwin.gdb. I hope it helps. Thread 1 "kwin_x11" received signal SIGINT, Interrupt. 0x00007fe0da57156e in ppoll () from /usr/lib/libc.so.6 Thread 10 (Thread 0x7fe0ce58e640 (LWP 51981) "QSGRenderThread"): #0 0x00007fe0d9ddc6a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x00007fe0da9220d4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt5Core.so.5 #2 0x00007fe0d96d52fb in () at /usr/lib/libQt5Quick.so.5 #3 0x00007fe0d96d789b in () at /usr/lib/libQt5Quick.so.5 #4 0x00007fe0da91be8f in () at /usr/lib/libQt5Core.so.5 #5 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #6 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 9 (Thread 0x7fe0cc850640 (LWP 34522) "kwin_x11"): #0 0x00007fe0d9ddc6a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x00007fe0da26afee in () at /usr/lib/libQt5Script.so.5 #2 0x00007fe0da26b019 in () at /usr/lib/libQt5Script.so.5 #3 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #4 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 8 (Thread 0x7fe0bcbf8640 (LWP 34477) "kwin_x1:disk$3"): #0 0x00007fe0d9ddc6a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x00007fe0beced8dc in () at /usr/lib/dri/iris_dri.so #2 0x00007fe0beced7d8 in () at /usr/lib/dri/iris_dri.so #3 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #4 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 7 (Thread 0x7fe0bd3f9640 (LWP 34476) "kwin_x1:disk$2"): #0 0x00007fe0d9ddc6a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x00007fe0beced8dc in () at /usr/lib/dri/iris_dri.so #2 0x00007fe0beced7d8 in () at /usr/lib/dri/iris_dri.so #3 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #4 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 6 (Thread 0x7fe0bdbfa640 (LWP 34475) "kwin_x1:disk$1"): #0 0x00007fe0d9ddc6a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x00007fe0beced8dc in () at /usr/lib/dri/iris_dri.so #2 0x00007fe0beced7d8 in () at /usr/lib/dri/iris_dri.so #3 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #4 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 5 (Thread 0x7fe0be3fb640 (LWP 34474) "kwin_x1:disk$0"): #0 0x00007fe0d9ddc6a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x00007fe0beced8dc in () at /usr/lib/dri/iris_dri.so #2 0x00007fe0beced7d8 in () at /usr/lib/dri/iris_dri.so #3 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #4 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 4 (Thread 0x7fe0cdabc640 (LWP 34410) "QQmlThread"): #0 0x00007fe0da57156e in ppoll () at /usr/lib/libc.so.6 #1 0x00007fe0dab568ab in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5 #2 0x00007fe0dab57fed in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #3 0x00007fe0dab0065c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #4 0x00007fe0da91aca2 in QThread::exec() () at /usr/lib/libQt5Core.so.5 #5 0x00007fe0d938c4b9 in () at /usr/lib/libQt5Qml.so.5 #6 0x00007fe0da91be8f in () at /usr/lib/libQt5Core.so.5 #7 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #8 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 3 (Thread 0x7fe0cf79f640 (LWP 34353) "QDBusConnection"): #0 0x00007fe0da57156e in ppoll () at /usr/lib/libc.so.6 #1 0x00007fe0dab568ab in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5 #2 0x00007fe0dab57fed in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #3 0x00007fe0dab0065c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #4 0x00007fe0da91aca2 in QThread::exec() () at /usr/lib/libQt5Core.so.5 #5 0x00007fe0dbc05098 in () at /usr/lib/libQt5DBus.so.5 #6 0x00007fe0da91be8f in () at /usr/lib/libQt5Core.so.5 #7 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #8 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 2 (Thread 0x7fe0d4a99640 (LWP 34335) "QXcbEventQueue"): #0 0x00007fe0da57146f in poll () at /usr/lib/libc.so.6 #1 0x00007fe0da82e63b in () at /usr/lib/libxcb.so.1 #2 0x00007fe0da83037b in xcb_wait_for_event () at /usr/lib/libxcb.so.1 #3 0x00007fe0d4bd1f61 in () at /usr/lib/libQt5XcbQpa.so.5 #4 0x00007fe0da91be8f in () at /usr/lib/libQt5Core.so.5 #5 0x00007fe0d9dd63e9 in start_thread () at /usr/lib/libpthread.so.0 #6 0x00007fe0da57c293 in clone () at /usr/lib/libc.so.6 Thread 1 (Thread 0x7fe0d4fc5cc0 (LWP 34306) "kwin_x11"): #0 0x00007fe0da57156e in ppoll () at /usr/lib/libc.so.6 #1 0x00007fe0dab567c1 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5 #2 0x00007fe0dab57fed in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #3 0x00007fe0d4bd336f in () at /usr/lib/libQt5XcbQpa.so.5 #4 0x00007fe0dab0065c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #5 0x00007fe0dab08af4 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #6 0x000055949e1b8412 in () #7 0x00007fe0da4a4152 in __libc_start_main () at /usr/lib/libc.so.6 #8 0x000055949e1b894e in _start () A debugging session is active. Inferior 1 [process 34306] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal] [Inferior 1 (process 34306) detached] The program is not being run. [Thread 0x7f180d78b640 (LWP 1170) exited] [Thread 0x7f18106a8640 (LWP 1141) exited] [Thread 0x7f17ee5a1640 (LWP 1288) exited] [Thread 0x7f17fcf96640 (LWP 1287) exited] [Thread 0x7f17fd797640 (LWP 1286) exited] [Thread 0x7f17fdf98640 (LWP 1285) exited] [Thread 0x7f180f3eb640 (LWP 1143) exited] [Thread 0x7f1810bd4cc0 (LWP 1129) exited] [Inferior 1 (process 1129) exited normally]
>KWin stops working when I close my laptop lid. That's an interesting datapoint. Does it always break after the first suspend? Can you reproduce toggling compositing off and on alt+shift+f12?
Could you also see if: sudo udevadm trigger -s input reliably triggers it?
Created attachment 133659 [details] attachment-6306-0.html The binding always breaks after first suspend. I pressed *alt+shift+f12* and the screen blinked. I then closed the lid and the binding broke. I restored with *kwin_x11 --replace & disown*. I restarted my machine for the next test because after I restore, I can't reliably reproduce the problem by closing the lid - it becomes random. But when I freshly login and close the lid I can break it 100% of the time. When I logged in after the restart, I entered *sudo udevadm trigger -s input* into the console It didn't trigger the meta key binding breakage. I then closed my laptop lid and I triggered the meta key binding breakage. On Wed, Nov 25, 2020 at 11:14 PM David Edmundson <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=391322 > > --- Comment #31 from David Edmundson <kde@davidedmundson.co.uk> --- > Could you also see if: > > sudo udevadm trigger -s input > > reliably triggers it? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You voted for the bug.
(In reply to David Edmundson from comment #31) > Could you also see if: > > sudo udevadm trigger -s input > > reliably triggers it? No, this doesn't trigger it for me. It does reliably trigger Bug 414559 though.
Just to confirm some things. If you run dbus-montior when it works you see the line: method call time=1607264891.373000 sender=:1.135 -> destination=org.kde.plasmashell serial=658 path=/PlasmaShell; interface=org.kde.PlasmaShell; member=activateLauncherMenu when it works you get nothing ---- As a next step can you run xkbcli interactive-x11 press meta then with it still open close the lid and reopen and press meta again and attach the whole log.
Created attachment 133912 [details] logs for xkbcli interactive-x11
All that typing gone when I attached that file! On a fresh restart, I ran 'dbus-monitor' from the terminal and streamed the output to kate. I grepped for 'member=activateLauncherMenu'. There were no hits. I launched kicker successfully and there was 1 hit. I closed the lid and activated the bug. I grepped again but got no new hits. The hit total stands at 1. I restarted my machine because I can 100% reproduce the bug on the first time. I setup my gdb and then ran 'xkbcli interactive-x11'. I pressed meta and then clicked on the desktop to close the menu. Then I launched kicker again, and with the menu open, I closed the lid. The bug activated. I restarted my pc to post the results and the log file (kwin.dbg). I'm happy to assist further.
That attached file doesn't look like the output of "xkbcli interactive-x11" it looks like a stack trace. Is it the right file?
hypothetically are you able to build your own kwin if I provided some patches?
(In reply to David Edmundson from comment #37) > That attached file doesn't look like the output of "xkbcli interactive-x11" > it looks like a stack trace. Is it the right file? Apologies. Here is the output: keysyms [ Super_L ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ XF86WakeUp ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] keysyms [ X
(In reply to David Edmundson from comment #38) > hypothetically are you able to build your own kwin if I provided some > patches? Yes I could. I'd like to help solve this bug.
That's interesting Am I to assume you suspended between the first and second lines?
I've got this reproducing 100% in my distro-provided Plasma 5.20 session, not my built-from source one. > run dbus-monitor When I press Meta I see the following: /PlasmaShell; interface=org.kde.PlasmaShell; member=activateLauncherMenu method return time=1607980254.054780 sender=:1.73 -> destination=:1.11 serial=4389 reply_serial=1138 ...But the menu doesn't appear. > run xkbcli interactive-x11 When I press Meta I see the following: keysyms [ Super_L ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] ...But the menu doesn't appear.
I think I have possibly found one reproducable way how to trigger this bug: Preconditions: - I have the application VLC media player maximized and in playlist mode (but probably any other app will do as well) - I am controlling the mouse via kde connect remote input Steps to reproduce: - hold the super key on the keyboard and double-tap with the finger in kde connect remote input - the vlc window will become half-transparent and the moving icon will appear - tap super several times while the window is still transparent - press ESC to stop the transparency -> super key shortcut has stopped working
I have made a screencast which is at https://drive.google.com/file/d/15mp2IYKzK9p-cDjdD-9qzA4GDGpqoWaW/view?usp=drivesdk
That gives a very solid working theory \o/ There's an interesting codepath in ModifierOnlyShortcuts: ``` if (event->type() == QEvent::MouseButtonPress) { m_buttonPressCount++; } else if (event->type() == QEvent::MouseButtonRelease) { m_buttonPressCount--; } ``` To track if the button is being held, so we don't fire for this meta + drag case. But if someone else does an xgrab through or someone else intercepts the event this will get out of sync. If this gets out of sync, we will never trigger meta code ever again.
Can I have your ~/.config/kwinrc please
My theory certainly works with one way to break it. type kwin_x11 --replace start holding a mouse button hit enter release m_buttonPressCount is now uint_max and meta key won't work unless you are pressing a key! Probably not the exact issue you're facing, but it could be a similar idea.
Is there any chance that a similar issue would also make kwin think the meta key is *constantly pressed*? I also experience that.
(In reply to David Edmundson from comment #46) > Can I have your ~/.config/kwinrc please https://pastebin.com/QcyFp33L
>Is there any chance that a similar issue would also make kwin think the meta key is *constantly pressed*? I also experience that. What are the symptoms?
Simply enough, everything acts as the meta key was constantly pressed. So when I try to e.g. type, I constantly activate meta+letter key combinations. When I try to select text from a window, I start dragging the window. And so on. I haven't found a reliable way to reproduce it, but I suspect it might have something to do with dragging whilst changing workspaces or something.
Here's a video: https://youtu.be/GMGeVA8LmRA It stops when I close the computer lid and open it again. If this is unrelated to this bug, I'll open a new bug report.
Ok, that's somewhat separate. That can't be a KDE bug (if we're on X)
Ah, not KDE's fault! Yes, it's X11. Thank you for the info!
Would be nice if this will be fixed in 5.21
*** Bug 384203 has been marked as a duplicate of this bug. ***
Any progress on this?
Bug is present after installing different application menu (start menu) from the built-in widget store. Changing in "kwinrc" is not helping. After assigning "Meta" + "F1", when only "Meta" key is pressed application menu is opening.
(In reply to remi from comment #58) > Bug is present after installing different application menu (start menu) from > the built-in widget store. Changing in "kwinrc" is not helping. After > assigning "Meta" + "F1", when only "Meta" key is pressed application menu is > opening. To be more precise I installed Ditto Menu.
Fix should be easy. After installing application menu widget (start menu) the "Meta" + "F1" or "Alt" + "F1" (as I read it is default) should be reassigned to use "Meta" key itself.
It stops working because after installing application menu widget (start menu) the "Alt" + "F1" key assignment is deleted.
*** Bug 435602 has been marked as a duplicate of this bug. ***
By chance, is this still an issue with Qt6?
(In reply to remi from comment #61) > It stops working because after installing application menu widget (start > menu) the "Alt" + "F1" key assignment is deleted. Maybe that's because the new application menu widget just doesn't have the "Alt" + "F1" key assignment by default? Or that accel should be shared among all the menu widgets? In that case, I wonder where the accel gets deleted?
The new Kickoff is definitely supposed to still have the same shortcut as the old one, because it was purely a UI redesign and nothing important in the backend changed. Do you see that we broke this?
No. Sorry, I didn't read it from the beginning. Seems we have different symptoms here.
*** Bug 436701 has been marked as a duplicate of this bug. ***
I wonder if this is related. "Meta" key is processed by Plasma even if other app currently grabbed the keyboard input. Examples: * xscreensaver: Pressing Meta activates Plasma menu even if the screen is locked! (security issue?) * VirtualBox with Win10 VM: Pressing Meta activates both Plasma and Windows Start menu...
I've had this issue for a while on different kernels and plasma versions. Happened today, but `xev` didn't show meta key at all. Turns out many keyboards have a lock setting for the meta key (or "Win-lock" or "W" lock or so on). My SteelSeries keyboard had a hidden mode I didn't know about, and pressing SteelSeries + Meta unlocked the "W" lock mode, and everything started working again. I've also had the problem without the lock, so this isn't a solution, but it's worth noting. There's a difference between the Meta key being locked (ie X-Server doesn't even register the key press) and the Meta keypress not triggering an event (ie X receives the key, but Plasma doesn't execute).
(In reply to Christoph Feck from comment #6) > If this happens again, please issue this dbus command: > > qdbus org.kde.plasmashell /PlasmaShell > org.kde.PlasmaShell.activateLauncherMenu > > If it shows the application launcher, the bug is in kwin. If it does not, > the bug is in plasmashell. I've had the same problem right after the installation and the very first update of Fedora 34 KDE. According to this test, the problem was in kwin. Since I have changed the config in ~/.config/kwinrc and reinstalled the kwin package via command "dnf reinstall kwin", I have not experienced the problem any more. My uptime is 10 day now, with a lot of standbys and resumes, changing monitors etc. and still working fine. I'm not sure if it's coincidence or not...
*** Bug 438612 has been marked as a duplicate of this bug. ***
I think I'm being affected by this bug as well. It started occuring when I changed the meta key to launch the menu on latte dock, and then after reverted back to using the default plasma panel. Confusingly, the global shortcut configuration "Activate Application Launcher Widget" in the plasma category, shows up three times.
(In reply to Jeffrey Bouter from comment #72) > I think I'm being affected by this bug as well. It started occuring when I > changed the meta key to launch the menu on latte dock, and then after > reverted back to using the default plasma panel. > > Confusingly, the global shortcut configuration "Activate Application > Launcher Widget" in the plasma category, shows up three times. The same thing happened to me when I reassigned META to the latte dock—an I also don't see the point to the three instances in global settings(?). Resetting META through global shortcuts accomplished nothing. Right clicking on the app/widget in the panel allowed me to successfully reset the META key and also fixed the problem with my inability to invoke the Applications Launcher via the touchscreen. https://bugs.kde.org/show_bug.cgi?id=438612
(In reply to PGillespie from comment #73) > (In reply to Jeffrey Bouter from comment #72) > > I think I'm being affected by this bug as well. It started occuring when I > > changed the meta key to launch the menu on latte dock, and then after > > reverted back to using the default plasma panel. > > > > Confusingly, the global shortcut configuration "Activate Application > > Launcher Widget" in the plasma category, shows up three times. > > The same thing happened to me when I reassigned META to the latte dock—an I > also don't see the point to the three instances in global settings(?). > Resetting META through global shortcuts accomplished nothing. Right clicking > on the app/widget in the panel allowed me to successfully reset the META key > and also fixed the problem with my inability to invoke the Applications > Launcher via the touchscreen. > > https://bugs.kde.org/show_bug.cgi?id=438612 Sadly, this didn't work for me either :-(
(In reply to Jeffrey Bouter from comment #74) > Sadly, this didn't work for me either :-( I followed these steps first: https://userbase.kde.org/Plasma/Tips#Windows.2FMeta_Key Though that still may not help you?
> I followed these steps first: > https://userbase.kde.org/Plasma/Tips#Windows.2FMeta_Key > Though that still may not help you? Sadly.. no :-( Thanks for the link though!
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1141
Git commit 8da06a0bdb8d519198df597dd454bc03056512b8 by Andrey Butirsky. Committed on 06/07/2021 at 10:43. Pushed by butirsky into branch 'master'. fix Meta key randomly stops opening Plasma launcher menu M +2 -6 src/modifier_only_shortcuts.cpp M +1 -1 src/modifier_only_shortcuts.h https://invent.kde.org/plasma/kwin/commit/8da06a0bdb8d519198df597dd454bc03056512b8
I couldn't reproduce the issue myself, so this is just probable fix. Please test it and report back. Thanks!
Woohoo! Thanks Andrey!
*** Bug 442614 has been marked as a duplicate of this bug. ***
Still happening to me. When I restart my computer, everything's well until I open either Chrome, Chromium or Brave. Then it doesn't work anymore. Still listens if I press Alt+F1 manually. Weird... Even weirder is this only started happening after I installed Brave. I deleted it since but it's happening with plain Chromium now, too. Plasma version: 5.23.4 Chromium version: 96.0.4664.110
The same problem happened to me after upgrading to framework 5.89 and after Plasma crashed due to bug #447925 then Meta key stopped being able to trigger Kickoff, the weird thing is that I cannot set it again in Kickoff settings and someone on Reddit proposed to set there to Meta+F1 and magically Meta (without F1) can again invoke Kickoff launcher !
Your issue is probably something else. It sounds like the shortcut actually got lost on Plasma's side. I actually had this happen to me once recently as well and was going to wait until it happened a second time before filing a bug report about it, but if it happened to you too, it's probably a real issue. Can you please file a new bug report about it? Thanks!
Hi Nate and Medin, I have experienced the same issue and adding back Alt+F1 seems to fix it. Had it happen on both Tumbleweed and Fedora. Interestingly, I had it happend after a few (~4) days of use, after adding it back it doesn't happen again.
After update to 5.24.1 this issue is occurring on Neon User Edition. Alt+F1 will open menu but Meta key will not, removing the keybinding and resetting to Alt+F1 does not make the Meta key work.
What does `grep -A 5 ModifierOnlyShortcuts ~/.config/kwinrc` say?
(In reply to Nate Graham from comment #87) > What does `grep -A 5 ModifierOnlyShortcuts ~/.config/kwinrc` say? That returns nothing.
Thanks. If you right-click on your Application Launcher applet, click on "Configure", and go to the "Keyboard Shortcuts page", can you verify that it shows Alt+F1 set as the shortcut?
(In reply to Nate Graham from comment #89) > Thanks. If you right-click on your Application Launcher applet, click on > "Configure", and go to the "Keyboard Shortcuts page", can you verify that it > shows Alt+F1 set as the shortcut? It is set . And pressing Alt+F1 does open Menu
OK, then the issue is indeed in KWin, then.
*** Bug 450365 has been marked as a duplicate of this bug. ***
*** Bug 447609 has been marked as a duplicate of this bug. ***
*** Bug 446525 has been marked as a duplicate of this bug. ***
I have the same issue with the application menu widget in my latte top panel. For me, it seems like the issue can randomly start happening even during normal usage, not just after sleep. The time it takes for the issue to start after every reboot varies, but once it happens once, it'll start to reoccur every 10 minutes or so (after which I restart kwin without rebooting and wait another 10 min)
If you are using easystroke-git in AUR (https://aur.archlinux.org/packages/easystroke-git) , it will cause the meta key to fail after successfully triggering a mouse gesture. You must click the trigger key again. I use plasma 5.24.5 in manjaro I hope my feedback is useful to you
I started to experience this bug after updating to 5.25, on wayland and nvidia proprietary driver. egl-wayland was also updated among other things during a system update. (In reply to Christoph Feck from comment #6) > If this happens again, please issue this dbus command: > > qdbus org.kde.plasmashell /PlasmaShell > org.kde.PlasmaShell.activateLauncherMenu > > If it shows the application launcher, the bug is in kwin. If it does not, > the bug is in plasmashell. For me the menu DOES NOT open with the given command once the bug starts to occur. In addition: Kicker stops working as well, Application Dashboard stops working the same way, All tooltips in plasmashell stop working. I don't have a precise way of reproducing this other than pressing the meta key repeatedly a couple times in quick succession.
That's a different bug: Bug 455575.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1937
Git commit 40d6e18b0f153464a64b3e21c1224e13511632d2 by Nate Graham, on behalf of David Redondo. Committed on 04/08/2022 at 16:23. Pushed by ngraham into branch 'master'. Take active screen in account and remove shortcut requirement for activating launcher With the information about the active screen we can make an educated guess about where the attention of the user is and where they could expect the launcher to open. If on the screen no launcher could be activated, look at all launchers. Also remove the requirement for launchers to have a shortcut. This is needed to make this feature work reliably and should reduce the instances of "Meta key stopped working" happening in general. Related: bug 444343, bug 437979, bug 447962 M +29 -9 shell/shellcorona.cpp M +1 -0 shell/shellcorona.h https://invent.kde.org/plasma/plasma-workspace/commit/40d6e18b0f153464a64b3e21c1224e13511632d2
(In reply to Nate Graham from comment #100) > Git commit 40d6e18b0f153464a64b3e21c1224e13511632d2 by Nate Graham, on > behalf of David Redondo. > Committed on 04/08/2022 at 16:23. > Pushed by ngraham into branch 'master'. > > Take active screen in account and remove shortcut requirement for activating > launcher > > With the information about the active screen we can make an educated > guess about where the attention of the user is and where they could > expect the launcher to open. If on the screen no launcher could be > activated, look at all launchers. Also remove the requirement for > launchers to have a shortcut. This is needed to make this feature > work reliably and should reduce the instances of "Meta key stopped working" > happening in general. > Related: bug 444343, bug 437979, bug 447962 > > M +29 -9 shell/shellcorona.cpp > M +1 -0 shell/shellcorona.h > > https://invent.kde.org/plasma/plasma-workspace/commit/ > 40d6e18b0f153464a64b3e21c1224e13511632d2 Now it's impossible to trigger launcher on Meta if it's not on panel. Also now I can't unbind Meta from it in other case, previously I bound it to other thing.
It still activates launchers not in the panel just prefer them - as before. I plan to make modifier only shortcuts fully configurable in the shortcuts kcm