SUMMARY LXQt has its own global keyboard shortcuts service (lxqt-globalkeysd), which autostarts in LXQt, as it should. However installing Plasma and LXQt on the same system results in both lxqt-globalkeysd and kglobalaccel5 starting up in LXQt. When logging in via LXQt, only LXQt desktop related services should be auotstarted, not KDE ones. Therefore this is a but in the KDE system for not marking kglobalaccel5 as KDE-specific. Currently, both these services are competing for the same hotkeys. STEPS TO REPRODUCE 1. Install both KDE/Plasma and LXQt. 2. Login on LXQt 3. in a terminal, execute: pgrep -a ".*global.*" OBSERVED RESULT % pgrep -a ".*global.*" 1211 /usr/bin/lxqt-globalkeysd --daemon 1423 /usr/bin/kglobalaccel5 On some logins, the KDE hotkeys are honored, and at other times LXQt ones. EXPECTED RESULT Only lxqt-globalkeysd should be running. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 5.11.11-arch1-1, plasma-framework 5.80.0-1, plasma-desktop 5.21.3-1 KDE Plasma Version: KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 (built against 5.15.2) ADDITIONAL INFORMATION
kglobalaccel5 is the KDE equivalent of lxqt-globalkeysd. It should only be autostarted when you're in a Plasma session. Are you saying that it gets autostarted when you're in an LXQt session too? Do any other KDE processes get autostarted, or just kglobalaccel?
Technically it isn't autostarted at all, it's DBus-activated. What probably happens is that some KDE software you are running calls some API of the KGlobalAccel which then makes a DBus call to the kglobalaccel daemon, resulting in it getting started. Preventing that from happening is easy enough, but before I make a patch doing so I want to check that I'm not missing a legitimate use case. Let's wait for some feedback on https://mail.kde.org/pipermail/kde-devel/2021-April/000406.html
(In reply to Nate Graham from comment #1) > Are you saying that it gets autostarted when you're in an LXQt session too? Yes, it gets autostarted in LXQt too. > Do any other KDE processes get autostarted, or just kglobalaccel? I logged in a brand new login id called "ethan" and ran "pgrep -aU ethan > ethan-procs.txt". This user has no customized configuration. I have pasted the contents below. The summary is that kdeconnect and kwallet autostart too, but I don't mind them. KWallet does not get in my way, so I don't care about it autostarting, and kdeconnect is something I use in LXQt, so I'm happy with it autostarting. To the LXQt session, kglobalaccel5 and krunner are the harmful processes. kactivitymanagerd and baloorunner are minor annoyances in LXQt too, but they don't get in the way of the LXQt session, they only consume some RAM. Incidentally, krunner, kactivitymanagerd and baloorunner don't autostart in my regular login (not ethan), so they can probably be controlled via the LXQt or Plasma configuration. % cat ethan-procs.txt 1057 /usr/lib/systemd/systemd --user 1058 (sd-pam) 1068 /usr/bin/kwalletd5 --pam-login 7 8 1069 lxqt-session 1074 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only 1102 /usr/bin/openbox --config-file /home/ethan/.config/openbox/lxqt-rc.xml 1107 /usr/bin/kaccess 1108 /usr/bin/pcmanfm-qt --desktop --profile=lxqt 1109 /usr/bin/lxqt-globalkeysd 1110 /usr/bin/lxqt-notificationd 1111 /usr/bin/lxqt-panel 1112 /usr/bin/lxqt-policykit-agent 1113 /usr/bin/lxqt-runner 1116 /usr/bin/xscreensaver -no-splash 1118 /usr/bin/nm-applet 1121 /usr/lib/kdeconnectd 1122 xscreensaver-systemd 1124 /usr/bin/kgpg 1137 /usr/bin/kglobalaccel5 1145 /usr/lib/dconf-service 1152 /usr/lib/at-spi-bus-launcher 1158 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 1173 /usr/lib/at-spi2-registryd --use-gnome-session 1277 /usr/bin/pipewire-pulse 1282 /usr/bin/pipewire 1283 /usr/bin/pipewire-media-session 1315 /usr/bin/lxqt-powermanagement 1350 /usr/bin/gpg-agent --supervised 1362 /usr/bin/krunner 1374 /usr/lib/kactivitymanagerd 1393 /usr/lib/baloorunner 1397 kdeinit5: Running... 1398 /usr/lib/kf5/klauncher --fd=8 1403 /usr/bin/qps 1419 /usr/bin/kitty 1427 /bin/bash
(In reply to Nicolas Fella from comment #2) > Preventing that from happening is easy enough, but before I make a patch > doing so I want to check that I'm not missing a legitimate use case. The first thing I do on each login on LXQt is execute: pkill ".*global.*" && lxqt-globalkeysd --daemon I plan to automate this part, but haven't gotten around to it yet. So if it helps answer the question of the use case, I need to kill the process to make my LXQt session function in a normal manner.
What probably happens is that kaccess is autostarted (since it is in /etc/xdg/autostart) and that triggers kglobalaccel. I guess kaccess should be changed to only autostart in Plasma then
Git commit f701c66dc37343bfb01062aa09dc4a2040ea7d4c by Nicolas Fella. Committed on 08/04/2021 at 12:52. Pushed by nicolasfella into branch 'master'. Only start kaccess in Plasma kaccess is an implementation detail of Plasma. It should not be launched when the user is running another DE while Plasma is installed. M +1 -0 kaccess/kaccess.desktop https://invent.kde.org/plasma/plasma-desktop/commit/f701c66dc37343bfb01062aa09dc4a2040ea7d4c
(In reply to Nicolas Fella from comment #6) Thank you! I made this change in my own /etc/xdg/autostart/kaccess.desktop, and it fixed the problem. Should I mark the bug as resolved or will that be done by the dev team?
(In reply to prash from comment #7) Sorry, I wrote to soon. The change to kaccess.desktop only partially fixes the problem. kglobalaccel5 no longer autostarts on login, but it starts the moment I start dolphin. Presumably, many other KDE apps might trigger it to start too.
(In reply to prash from comment #8) After a bit of triangulating, it appears that merely opening a KDE app will not autostart kglobalaccel5. On a fresh session, when I opened Okular, there were no processes that were out of the ordinary. However, the moment I did a File->Open or File->Open Recent from there, I got something like this: 12590 /usr/lib/kactivitymanagerd 12599 /usr/bin/kglobalaccel5 Of course, dolphin starts these processes too. Again, on fresh sessions, KCalc, KCharSelect, KDiff3, Kompare did not trigger kactivitymanagerd or kglobalaccel5, even after performing a File->Open or an equivalent. I have no idea why both dolphin and okular would repeatably trigger these.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/19
Git commit 48c3376927e5e9c13377bf3cfc8b0c411783e7f3 by Nicolas Fella. Committed on 19/04/2021 at 22:26. Pushed by nicolasfella into branch 'master'. Prevent kglobalaccel5 getting activated on non-Plasma systems While in theory kglobalaccel works on any X11 system we don't want it to run on non-Plasma systems. It isn't very useful and may interfere with the desktop's native shortcut system. Calling some API of KGlobalAccel may result in a DBus call to the daemon which then may launch by DBus activation. Prevent that from happening on non-Plasma systems. Related: bug 430691 M +80 -0 src/kglobalaccel.cpp https://invent.kde.org/frameworks/kglobalaccel/commit/48c3376927e5e9c13377bf3cfc8b0c411783e7f3
I am not sure this is a step in the right direction. I am using KWin + LXQt and KWin relies on kglobalaccel5. Thus KWin without KDE is basically broken with this patch, unless the user finds out about this behavior. Then there is a larger discussion if disabling all application's global shortcuts unless you are running on KDE is what the user wants. To me it seems the breakage is bigger if we deactivate kglobalaccel5. Unfortunately I do not have a clear idea what to do. Could the original report give us some info on which are the clashing hotkeys? Maybe there would be some way to distinguish plasma-specific hotkeys?
So you don't want kglobalaccel to run when Plasma is also installed but not active, and you do want it to run when using KWin as the window manager in LXQt?
(In reply to Nate Graham from comment #13) > So you don't want kglobalaccel to run when Plasma is also installed but not > active, Well that is what @prash wanted, not me. I understand where he is coming from (colliding keyboard shortcuts), but it silently breaks my use-case. And I believe that it is not an ideal solution in general. Case in point, Amarok has some useful global shortcuts using KGlobalAccel [1], e.g. for skipping tracks, that you would like to work even if the current environment is not plasma. Currently, these shortcuts will stop working. > and you do want it to run when using KWin as the window manager in > LXQt? KWin is pretty unusable without kglobalaccel (even alt-tab does not work). Or at least it seems to me that KWin needs it running (from quick look at the sources), maybe there is other way? I personaly have no problem setting the XDG_CURRENT_DESKTOP=KDE environment variable or patching kglobalaccel, I just wanted to inform you abot these issues. And maybe provide users with broken KWin shortcuts something to search for :). [1]https://github.com/KDE/amarok/blob/e09665e6b1298de7a8e442a7d530d4ec23ab283f/src/MainWindow.cpp#L957
> Amarok has some useful global shortcuts using KGlobalAccel [1], e.g. for skipping tracks, that you would like to work even if the current environment is not plasma. Currently, these shortcuts will stop working. That is true, but for media players the basic shortcuts (play, pause, skip, back) should *not* be handled by the app itself but by the MPRIS integration. Also, there is a tradeoff to be made, and we considered not breaking a systems shortcut system more important than having shortcuts in Amarok. IMO the proper solution would be to make lxqt-globalkeysd trigger the relevant stuff in KWin. It probably requires some work on KWin to expose the necessary bits as DBus API, but in the end it's the best solution
I'm not sure if if you still need me to list out the clashing hotkeys. There are quite a lot of them (if I add openbox+lxqt vs KDE). A more general solution I would prefer is if you could make all these services configurable from their respective .desktop files with: OnlyShowIn=KDE Could you also please look controlling the autostart of kactivitymanagerd in a similar manner? That way, the user who wants the service can copy the relevant file from /etc/xdg/autostart to ~/.config/autostart and modify the line to OnlyShowIn=KDE;LXQt After all, this is the standard way of controlling services in LXQt, and maybe other DEs.
Git commit 9a48818abf50340e31d718cc675501dec6c51429 by Nate Graham. Committed on 26/05/2021 at 19:14. Pushed by ngraham into branch 'master'. Revert "Prevent kglobalaccel5 getting activated on non-Plasma systems" This reverts commit 48c3376927e5e9c13377bf3cfc8b0c411783e7f3. This change broke users of KGlobalAccel run outside of the Plasma Desktop. This sort of behavior change probably needs to be made during a major transition like KF6 so that developers have some notice and it doesn't randomly change and break stuff unexpectedly. Related: bug 437034 FIXED-IN: 5.83 M +0 -80 src/kglobalaccel.cpp https://invent.kde.org/frameworks/kglobalaccel/commit/9a48818abf50340e31d718cc675501dec6c51429
The change was reverted as it broke legitimate users of KGlobalAccel outside of Plasma. Re-opening this.
(In reply to Nate Graham from comment #18) > The change was reverted as it broke legitimate users of KGlobalAccel outside > of Plasma. Re-opening this. Could you please make the autostart of kactivitymanagerd and kglobalaccel5 manageable via their .desktop files? This will solve the issue for both kinds of use-cases. People can configure its autostart from within ~/.config/autostart.
As I have mentioned before kglobalaccel is not autostarted via the usual autostart mechanism. The process is launched via DBus activation the first time something makes an API call to it