It looks like I successfully trolled a few people yesterday. Given that I don't do tabloid style postings without an explanation it should have been obvious that the comment is not meant like it's written. Nevertheless some reactions are predictable and I wanted to highlight this with the post: you cannot even mention parts of the systemd ecosystem without people jumping to conclusions and going so far to threaten to abandon the project although there is no data around what it means at all. A rational discussion on that ground is not possible and I think this needs to change fast.

Although the post is tabloid style it carried quite some information. I explicitly restricted to kwin_wayland. This implies that kwin_x11 is not affected. It also doesn't mean anything for other KDE software or Plasma. It's just kwin_wayland.

Second of all it says "runtime depend on logind". Notice that it doesn't say systemd, it's logind. And runtime depend indicates that it's only interacting with the DBus interface provided by logind. I don't understand how people could think that this means systemd as an init system is demanded given that there is a large distribution using logind without systemd.

Now why does kwin_wayland need to use logind's dbus interfaces? It's quite simple: I started integrating libinput into kwin_wayland and run into the obvious problem that one needs to be privileged to open the input devices. Running kwin_wayland with suid bit is a no-option, going to complicated wrappers is a no-option. Logind on the other hand allows the session controller to take a device and opens it for the session controller and returns the file descriptor. In addition it notifies whether the session is active. This is exactly what we need: it manages the device files in a secure way and we get notified when we need to suspend/resume the device files.

Obviously the required dbus interface could easily be provided without requiring logoind. I myself implemented a fake logind service for unit tests in the screen locker daemon and I will move that fake logind also to kwin to properly unit test that code. So this is possible.

And now how important is the dependency. Well I called it a "hard runtime dependency" which means that I consider kwin_wayland to have deficits if not used. Nevertheless the complete code is in an ifdef section (libinput is an optional build dependency) and there is even a command line option to disable libinput in kwin_wayland. kwin_x11 does not even try to use it. But yes if you want to use kwin_wayland in a Wayland session you will only get the full experience with libinput and the required logind integration used in KWin's libinput module.

The solution I picked will work for the large majority of our user base without introducing security risks. If there are other solutions which would provide us the same I'm happy to take patches, though I'm not interested in complicating the code base.
Breaking News: kwin_wayland will hard runtime depend on logind
Shared publiclyView activity