Triggering Kando over and over crashes dbus-broker, crashing the entire desktop (kwin_wayland)

[auslegungssache]

Short Summary

I use Kando to switch music. This involves triggering it very often in a certain amount of time. This usually eventually leads to a complete crash of the desktop due to dbus-broker (or dbus-broker-launch) crashing (see logs). Especially if I do this very often in a certain amount of time.

Steps to Reproduce the Issue

1. Use KDE Plasma 6.3.2 with Wayland
2. Trigger Kando over and over
   Example: watch -n 0.5 flatpak run menu.kando.Kando -m "Main"
3. The dbus broker soon crashes and takes the entire desktop down with it, segfaulting every application in the session

Kando Version

v1.7.0

Installation Method

Another method (specify in the comments below)

Desktop Environment

KDE on Wayland

Environment Version

KDE Plasma 6.3.2, OpenSUSE Tumbleweed

Additional Information

I have tested this issue with multiple ways of triggering Kando. Be it through my keyboard, my mouse bound to a key or even the command line, it still does it.
I have also tried to see if this is caused by any of my other extensions. Sadly it occurs even on vanilla Plasma.

The issue happens irregardless of if Kando is run as an AppImage, Flatpak or anything else.

While I do think this is a bug in dbus_broker, the issue also seems partially to be on the side of Kando. I think this could be caused by Kando creating a high amount of chatter, which then crashes dbus. That could however be wrong on my side

Logs:

Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Triggered.
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Triggered.
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Received data request.
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Successfully transmitted the data.
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Registered shortcut main-menu
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Triggered.
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Triggered.
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Received data request.
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Successfully transmitted the data.
Mar 12 19:51:18 moon kwin_wayland[2976]: js: Kando: Registered shortcut main-menu
Mar 12 19:51:19 moon kwin_wayland[2976]: js: Kando: Triggered.
Mar 12 19:51:19 moon kwin_wayland[2976]: js: Kando: Triggered.
Mar 12 19:51:19 moon kwin_wayland[2976]: js: Kando: Received data request.
Mar 12 19:51:19 moon dbus-broker-launch[2955]: ERROR sockopt_get_peerpidfd @ ../src/util/sockopt.c +244: Too many open files
Mar 12 19:51:19 moon dbus-broker-launch[2955]:       peer_new_with_fd @ ../src/bus/peer.c +290
Mar 12 19:51:19 moon dbus-broker-launch[2955]:       listener_dispatch @ ../src/bus/listener.c +54
Mar 12 19:51:19 moon dbus-broker-launch[2955]:       dispatch_context_dispatch @ ../src/util/dispatch.c +344
Mar 12 19:51:19 moon dbus-broker-launch[2955]:       broker_run @ ../src/broker/broker.c +229
Mar 12 19:51:19 moon kwin_wayland[2976]: js: Kando: Successfully transmitted the data.
Mar 12 19:51:19 moon systemd[2801]: Got disconnect on API bus.
Mar 12 19:51:19 moon wireplumber[3077]: m-dbus-connection: <WpDBusConnection:0x556c00b6d460> DBus connection closed: Underlying GIOStream returned 0 bytes on an async read
Mar 12 19:51:19 moon flatpak[3781]: [2 preload-host-spawn-strategy] Dropping 0xe400004c6c0 (3) because of connection closed
Mar 12 19:51:19 moon systemd[2801]: obex.service: Main process exited, code=exited, status=1/FAILURE
Mar 12 19:51:19 moon gvfsd[3647]: A connection to the bus can't be made
Mar 12 19:51:19 moon systemd[2801]: obex.service: Failed with result 'exit-code'.
Mar 12 19:51:19 moon dbus-broker[3629]: Dispatched 706 messages @ 2(±3)μs / message.
Mar 12 19:51:19 moon flatpak[3780]: [2 preload-host-spawn-strategy] Dropping 0x39480004c6c0 (3) because of connection closed
Mar 12 19:51:19 moon 1password[3713]: [3713:0312/195119.091844:FATAL:bus.cc(1246)] D-Bus connection was disconnected. Aborting.
Mar 12 19:51:19 moon flatpak[3780]: [2:36:0312/195119.092948:FATAL:bus.cc(1247)] D-Bus connection was disconnected. Aborting.
Mar 12 19:51:19 moon flatpak[3781]: [2:34:0312/195119.092748:FATAL:bus.cc(1247)] D-Bus connection was disconnected. Aborting.
Mar 12 19:51:19 moon flatpak[3926]: [0312/195119.093041:ERROR:scoped_ptrace_attach.cc(27)] ptrace: Operation not permitted (1)
Mar 12 19:51:19 moon flatpak[3925]: [0312/195119.092831:ERROR:scoped_ptrace_attach.cc(27)] ptrace: Operation not permitted (1)
Mar 12 19:51:19 moon wireplumber[3077]: m-dbus-connection: <WpDBusConnection:0x556c00b6d460> Trying to reconnect after core sync
Mar 12 19:51:19 moon systemd[2801]: xdg-permission-store.service: Main process exited, code=exited, status=1/FAILURE
Mar 12 19:51:19 moon systemd[2801]: xdg-permission-store.service: Failed with result 'exit-code'.
Mar 12 19:51:19 moon systemd[2801]: xdg-document-portal.service: Main process exited, code=exited, status=20/n/a
Mar 12 19:51:19 moon dbus-broker[2955]: Dispatched 24923 messages @ 3(±9)μs / message.
Mar 12 19:51:19 moon dbus-broker-launch[2955]:       run @ ../src/broker/main.c +261
Mar 12 19:51:19 moon dbus-broker-launch[2955]:       main @ ../src/broker/main.c +295
Mar 12 19:51:19 moon systemd[2801]: flatpak-session-helper.service: Main process exited, code=exited, status=1/FAILURE
Mar 12 19:51:19 moon kdeconnectd[3458]: 2025-03-12T19:51:19 org.kde.pulseaudio: No object for name "alsa_output.pci-0000_12_00.6.analog-stereo"
Mar 12 19:51:19 moon dbus-broker-launch[2954]: Caught SIGCHLD of broker.
Mar 12 19:51:19 moon dbus-broker-launch[2954]: ERROR launcher_run @ ../src/launch/launcher.c +1453: Return code 1
Mar 12 19:51:19 moon dbus-broker-launch[2954]:       run @ ../src/launch/main.c +152
Mar 12 19:51:19 moon systemd[2801]: xdg-document-portal.service: Failed with result 'exit-code'.
Mar 12 19:51:19 moon systemd[2801]: flatpak-session-helper.service: Failed with result 'exit-code'.

[Schneegans]

Hi there! Thanks for the report and sorry for the delayed response (I was ill for the last week or so 🤒). I fear that this will be very hard to debug.

The only thing which comes to my mind is that the binding and unbinding of global shortcuts is implemented in a very weird way on KWin/Wayland using KWin scripts. And the hotkeys are unbound and rebound whenever a menu is shown.

You could test this - if you run Kando from source and remove this line and this line, this part of the D-Bus communication will be skipped.

Instructions for running Kando from source are here: https://kando.menu/compile-from-source/

[auslegungssache]

Thank you for your answer and so sorry for inactivity 😅

I tried out removing the lines but it sadly didn't help.

dbus-broker-launch[2955]: ERROR sockopt_get_peerpidfd @ ../src/util/sockopt.c +244: Too many open files

The actual error dbus broker error message leads me to believe, that this is caused by the script constantly being loaded, started, stopped and so forth.

Is there a specific reason, why it was implemented this way? Or is there anything that would speak against loading the script once and rolling trigger and sendWMInfo into a single call? If not, I could have a look into writing a patch.

Here you can see org.kde.kwin.Scripting.loadScript being called twice per invocation.

EDIT:
Forgot to mention - the script that gets loaded multiple times per invocation is the following:

[Schneegans]

Well, if you find a way to improve this, go for it! Back when I implemented this, I was happy that it worked at all 😅. So let's break this down a bit. There are two scripts used by the backend:

• The get-info.js is static and it could indeed be possible to load this only once. Maybe you could separate the loading from the starting.
• The contents of global-shortcuts.js changes every time when updateShortcuts is called. So this needs to be reloaded indeed quite frequently. I do not see a proper way to avoid this. Do you have an idea?

I think our best bet would be to remove this "hack" for binding global shortcuts altogether and use the global shortcuts portal instead. I think by now this is pretty widely supported.

I have not yet looked into this - however, I have the fear that this is not designed for our use-case. Currently Kando unbinds a menu's shortcut when the menu is shown so that Turbo-Mode works. I think that unbinding and rebinding a shortcut using the portal will not work without user interaction. But one would need to confirm this.

[auslegungssache]

Oh man this was such a rabbit hole. Wayland support for advanced use cases is still half baked at best...
I looked more into how exactly programs lan-mouse handle this, and I see two options. I want to ask you how you imagine this being solved, since I don't want to implement something that doesn't fit into your vision 😺

Two ways of solving it

"The Proper Way"

The way I understand it, simply switching to the Global Shortcuts API wouldn't really help us here, because we'd still need to register a script that then sends the window / mouse info to Kando.

For capturing the position of the mouse, we'd have to switch to the Input Capture API. That would also solve the problem with turbo-mode, as Kando could just handle the key binding by itself and not rely on the compositor handling shortcuts properly. I don't think there is a Node.JS library for actually processing LibEi events, so this would be non-trivial to implement.
I also looked into implementing this with just LibEi on its own, but although not documented, it seems that GNOME and KDE only let you interact with the API through the XDG portal 😓

The only real issue I see with this is that there is currently no way to capture the current window title / class, so that feature would just not work on Wayland for now 🤷‍♀

I think this would be the right and future proof way to do it moving forward. The Input Capture API is currently only supported on KDE, GNOME and Hyprland, but I think more will hop on later. This would allow us to remove some of the compositor-specific code as well.

As for implementing this:
I looked around for a Node.JS library that'd handle the XDG Portal / LibEi, but there doesn't really seem to be any. I think implementing that is wayyy outside the scope of this project 😭
Since Kando uses native addons for Hyprland support, we could use the C library libportal to handle this for us. I sadly have no experience with C / C++ so I can't help there.
The most developed and easy library for interfacing with these APIs is the Rust library ashpd (example of how to capture input events with it). It could then be connected with something like Neon. Maybe that is something we could look into?

The hacky way

We could move more of the logic into the kwin script.
The kwin scripting API has pretty bad docs, so I'll look the specifics of that later. There doesn't seem to be any interface, over which one could define new D-Bus methods (or does this have to be handled by registering a new service??)

Assuming this is the case, we could rewrite the scripts, so that:

1. the scripts only load once (at Kando startup)
2. Kando communicates with the script over some socket / port / dbus (?) - new shortcuts, updates etc.
3. trigger and sendWMInfo get rolled into a single call
4. the script gets unloaded when Kando exits

However, this sounds scope-wise more like a full blown kwin extension 🫠
Maybe the IPC between Kando and KWin could also be moved completely out of D-Bus. I'm also considering reporting this to dbus-broker, as it shouldn't ever crash because of this.

[Schneegans]

Create something like Kando with support for Wayland is indeed really painful. It took me really long to figure out that it is actually possible to register and call KWin scripts via D-Bus.

Regarding the "Proper Way"

The Input Capture API could potentially solve the issue of Turbo Mode. However, there is a good chance that it does not work. Just as a recap - the events here are as follows:

1. Kando registers a global shortcut with the compositor, lets say Ctrl+Space.
2. The user presses Ctrl+Space and Kando opens its window.
3. The user keeps Ctrl+Space pressed - at this point, the compositor should send mouse motion events to Kando indicating that Ctrl is still pressed. Usually, this does not work if the global shortcut is still registered. Maybe using the input capture API could help here, but I do not see how the captured input should be forwarded to the Kando. If I see it correctly, the input capture API will forward the input to a "libEI file descriptor". Getting this to Node.js will be a challenge in itself.

The real problem of replacing the get-info.js script is however the following: Kando requires the pointer position before opening the window. The menu should be opened at the pointer position. From what I tried, getting the pointer position on Wayland is only possible after the user moved the pointer over the client window. If the pointer is stationary, the compositor does not send any events to the client indicating the pointer position. Hence, I concluded that we will need some sort of compositor extension to get the pointer position before the window is opened.

What could be a solution?

Ideally, we would use the global shortcuts portal for binding shortcuts, and hope that it does not interfere too much with Turbo Mode. To get the application title and the pointer position, we will require something which hooks into the compositor. A KWin script is the only thing that I tried - do KWin extensions have more capabilities? For GNOME, I also use a custom extension for providing the required information via D-Bus. Maybe a KWin extension could also provide a D-Bus interface?

As you figured out we can use both C++ or any NodeJS code for that. Kando already uses the Remote Desktop Portal via JS under KDE/Wayland, so I am pretty confident that using the Global Shortcuts Portal could work in a similar fashion.

[Schneegans]

Electron 36 comes with builtin support for the global-shortcuts portal. I tested this and the implementation seems to be pretty mediocre. First, it has to be enabled via a command-line switch, second it is only enabled if the app runs as a Wayland client. So it simply doesn't work if we use XWayland (which is still the standard for Kando). Lastly, electron only allows binding shortcuts one by one. This causes the portal dialog to pop up once for each shortcut of the application which is pretty annoying.

So we need our own implementation!

While those issues may get fixed in the future, it will not happen anytime soon. So I decided to create our own implementation (#995). And I think it works pretty well! I had to do some pretty massive refactoring as Kando used the Electron approach of binding shortcuts one-by-one, but with the desktop portal you need to pass the entire set of shortcuts at once.

I am not sure if this fixes this issue. After all, it significantly reduces the amount of D-Bus communication between Kando and KWin. We still have the get-info script which returns the window title etc., but no script for binding the shortcuts anymore.

However, it improves the user experience on KDE Wayland anyways, as we can bind the shortcuts more or less directly from Kando, without having to search for some menu IDs in the system settings anymore!

Please test this!

You can download a test build from the bottom of this page: https://github.com/kando-menu/kando/actions/runs/15618764858 (the artifact named build-ubuntu-24.04). This contains all the different formats, you just run the AppImage, for instance.

If you want to be on the safe side, you may want to backup your config files before.

Does this work for you? Can you still reproduce the crash?

[Schneegans]

I have merged #995 as I am pretty sure that it will improve the user experience anyways. But I am not sure if it resolves this issue here. So please report any findings!