Anyone using kde-plasma with seatd?

[Zucca]

I was about to try out KDE/Plasma again since KDE 4 early days.
Then I realised that kde plasma required systemd-logind or elogind to function.

My systems mostly use seatd + greetd, sometimes only seatd.
I wonder if it's possible to run kde plasma on systems where systemd-logind and elogind are absent?

[Anon-E-moose]

I wonder if it's possible to run kde plasma on systems where systemd-logind and elogind are absent?

Not if you install by way of plasma-meta.
If you pick and choose pieces ... maybe.

Ones that will more than likely need *logind,

Code: Select all

 $ grep -lE "logind|systemd" */*ebuild
drkonqi-legacy/drkonqi-legacy-6.3.80_p20250417.ebuild
drkonqi/drkonqi-6.3.5-r1.ebuild
drkonqi/drkonqi-6.3.6.ebuild
drkonqi/drkonqi-6.4.2.ebuild
kwin-x11/kwin-x11-6.4.2.ebuild
kwin/kwin-6.3.5-r2.ebuild
kwin/kwin-6.3.6.ebuild
kwin/kwin-6.4.2.ebuild
plasma-firewall/plasma-firewall-6.3.5.ebuild
plasma-firewall/plasma-firewall-6.3.6.ebuild
plasma-firewall/plasma-firewall-6.4.2.ebuild
plasma-meta/plasma-meta-6.3.5-r2.ebuild
plasma-meta/plasma-meta-6.3.6.ebuild
plasma-meta/plasma-meta-6.4.2.ebuild
plasma-workspace/plasma-workspace-6.3.5-r2.ebuild
plasma-workspace/plasma-workspace-6.3.6.ebuild
plasma-workspace/plasma-workspace-6.4.2.ebuild
powerdevil/powerdevil-6.4.2.ebuild

[Chiitoo]

I have been wondering the same for a while now, but I'm guessing it's not possible at this time due to what is being expected to be there. I'll be happy to be wrong about that though, and I have not dug into too deep yet.

Well, almost the same. For me it is not Plasma, but LXQt + KWin. I haven't mapped the specific requirements for KWin Wayland there yet, as I did not get it running on my main machine, which normally has no *logind, pam, policykit, and other such friends, even after adding those, so must be missing some piece still.

I did get it running on another machine that /does/ have elogind and friends, so it is a bit puzzling.

[Zucca]

I considered installing elogind on that machine where I'd like to test out KDE, but then I stumbled upon Turnstile. So I'd still need seatd for seat management (I do want a seat aware system, I have use for it).

I've used /etc/security/pam_env.conf to set up custom environment variables for each user.
There was something elogind did and wasn't configurable that I switched to using seatd. One significant plus side seems to be that my systems don't have polkit (the idea of policy kit seems fine, but the implementation, which requires a javascript engine, is horrible).

I'll try to compare the features of elogind and turnstile, then maybe choose one of them to test.

(One more rabbit hole found, again.)

[Yamakuzure]

I considered installing elogind on that machine where I'd like to test out KDE, but then I stumbled upon Turnstile. So I'd still need seatd for seat management (I do want a seat aware system, I have use for it).

I do not know whether this is relevant, but I have Plasma+elogind and use weston for havin sddm being on wayland instead of X. Weston needs seatd, so it is installed with USE="elogind -builtin -server -systemd" and works just fine. /usr/lib64/libseat.so.1 just asks elogind instead of its own server then.

About Turnstile, I read their readme but have no real understanding what they are about.

For instance, they write

While there are workarounds such as elogind, these are far from ideal. For instance, elogind is just a stubbed out version of upstream logind, and only provides the bare minimum, so systems using it are left without support for user services and other useful functionality.

Well, elogind is not "stubbed out" but simply systemd-logind + some extras. It is explicitly _not_ a service manager, that would have been the core of systemd, and would make elogind useless when run by actual service managers like openrc. And unfortunately they don't elaborate on the "other useful functionality", so I have no idea what I am missing.

It is sad that people start projects with readmes that bash other projects in secret instead of talking open what they are missing.

[Zucca]

Well, elogind is not "stubbed out" but simply systemd-logind + some extras.

Interesting. What extras?

[GDH-gentoo]

I wonder if it's possible to run kde plasma on systems where systemd-logind and elogind are absent?

Expanding on Anon-E-moose's answer: sys-auth/elogind gets pulled only by kde-plasma/plasma-meta, because it installs sys-apps/dbus[elongind] and sys-fs/udisks[elogind]. Now, USE flag elogind makes sys-apps/dbus add extra code to dbus-daemon for processing configuration files that contain <policy at_console=value>, and makes sys-fs/udisks build the udisksd daemon (which does need either elogind or systemd-logind).

So I guess whether you can do away with elogind depends on what happens if one does not run udisksd, which packages drop D-Bus configuration files (in /usr/share/dbus-1/{system,session}.d) with attibute at_console in policy elements, and what for. You could do the experiment with your hand-picked Plasma packages

KWin doesn't seem to need elogind, although kwin_wayland will talk to it (for session management) if it is using the DRM backend.

[Chiitoo]

Did some quick testing after updating a year-old install, and reminded myself of what happens when trying to start LXQt with 'kwin_wayland' with seatd running.

Suppose this is some kind of a permission issue (the device/file /is/ there):

Code: Select all

No backend specificed, automatically choosing drm
kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
kwin_wayland_drm: No suitable DRM devices have been found

If I set WAYLAND_DISPLAY, it will use the Wayland backend, but then it just... doesn't do anything if set to 'wayland-0' for example.

I /can/ start LXQt with 'kwin_wayland' inside a Wayfire LXQt session though... for whatever that is worth. :]

Last time I found a FreeBSD thread talking about running Plasma Wayland session, from which I got a lot of environment variables to try but not to any real success:

https://forums.freebsd.org/threads/tryi ... land.93951

Regarding udisks, I have been running LXQt with KWin without it for years, by removing the need for it from solid.

[Yamakuzure]

Well, elogind is not "stubbed out" but simply systemd-logind + some extras.

Interesting. What extras?

• eloginds loginctl has "list-sessions" as the default command.
• eloginds loginctl supports some systemctl commands, like: halt, poweroff, reboot, kexec, sleep, suspend, hibernate, hybrid-sleep and suspend-then-hibernate (*)
• eloginds loginctl supports --no-wall, --dry-run and --force options, systemds loginctl doesn't.
• elogind allows sleep/shutdown hook scripts to cancel sleep/shutdown. When enabled, the hook scripts run serialized. With systemd-sleep, all scripts always run in parallel and their outcome is ignored.
• elogind has a 'daemon-reload' command and 'Reload' dbus method, systemd-logind has neither.
• elogind comes with busctl, elogind-userdbd, userdbctl and varlinkctl. The userdb stuff is optional, of course. (**)
• ... and maybe more I just forgot about...

(*) kexec is currently re-implemented and fixed for the upcoming v257 release
(**) busctl is there for ages, the others are currently tested for the upcoming v257 release
(You can find a live ebuild in pg_overlay or seden overlays. As always with live ebuilds, use with care!)

Do those qualify as "extras"?

[Zucca]

Do those qualify as "extras"? :)

Sure. In my books at least.
Two questions:

• can I set my custom XDG_RUNTIME_DIR while using elogind? Maybe via pam_env?
• Does elogind work on musl based systems?

On the KDE side... so it seems that I'd need udisks? I don't have anything against udisks, but it seems to require polkit, which is a PITA on low end systems. Although on low end systems I don't use KDE, and there I also tend to use seatd in place of elogind.

[GDH-gentoo]

Did some quick testing after updating a year-old install, and reminded myself of what happens when trying to start LXQt with 'kwin_wayland' with seatd running.

Suppose this is some kind of a permission issue (the device/file /is/ there):

Code: Select all

No backend specificed, automatically choosing drm
kwin_wayland_drm: failed to open drm device at "/dev/dri/card0"
kwin_wayland_drm: No suitable DRM devices have been found

I see. Here's what happens for KWin 6.3.5:

1. kwin_wayland creates an object of a class derived from KWin::OutputBackend (KWin::DrmBackend for the default DRM backend) and an object of a class derived from KWin::Session.
2. The session object will be of class KWin::LogindSession if elogind is present, and fall back to KWin::NoopSession otherwise. That misled me.
3. All is good, until the KWin::DrmBackend object wants to add GPUs: it calls the session object's openRestricted() member function. If the session object is a KWin::LogindSession object, then no problem, a file descriptor is requested from elogind using the TakeDevice() method from the org.freedesktop.login1.Session D-Bus interface —which is also what Xorg does when running as an unprivileged process, by the way—. But
4. If the session object is a KWin::NoopSession object, the call fails unconditionally.

Conclusion: kwin_wayland with the DRM backend does seem to need either elogind or systemd-logind, same as Xorg for running as an unprivileged process. Someone would have to write a KWin::SeatdSession class and add the option to the KWin::s_availableSessions object, propose that upstream and have it accepted Assuming it is easy to map seatd's interface to the KWin::Session interface.

[Yamakuzure]

Do those qualify as "extras"?

Sure. In my books at least.
Two questions:

• can I set my custom XDG_RUNTIME_DIR while using elogind? Maybe via pam_env?
• Does elogind work on musl based systems?

• No, the user directory is fixed to /run/user/<uid>, and that directory is reported back to PAM as being the XDG_RUNTIME_DIR. (Hard-coded in src/login/logind-user.c::user_new()) - Making that one configurable would divert elogind from systemd-logind on that part. But if there is a good reason for it, go ahead and open an issue with a feature request.
• Yes, thanks to the help of the VOID people, elogind is musl-compatible. (And if I do something that changes that, they get me notified quickly via issues and PRs. )

[asturm]

[*]Yes, thanks to the help of the VOID people, elogind is musl-compatible. (And if I do something that changes that, they get me notified quickly via issues and PRs. :-) )[/list]

Are you absolutely sure? So far elogind has always needed substantial patching to build with musl:

Code: Select all

ls sys-auth/elogind/files/*musl* | wc -l
9

... and broke as soon as I had to drop these patches because I have no means nor energy to rebase all that onto newer versions [and do the required testing and setting up a musl image just for that], see also:
https://bugs.gentoo.org/939218
https://bugs.gentoo.org/940130
... hence

Code: Select all

# Sam James <sam@gentoo.org> (2024-09-30)
# Needs porting to musl (bug #940130)
~sys-auth/elogind-255.5
~sys-auth/elogind-255.17

[GDH-gentoo]

So far elogind has always needed substantial patching to build with musl:

This is a consequence of how much systemd developers are interested in portability

[...], see also:
https://bugs.gentoo.org/939218
https://bugs.gentoo.org/940130

Gentoo carries patchsets for different versions of sys-apps/systemd-utils on musl profiles. I don't know where these come from, but, from the one used for the 255 series, systemd-musl-patches-255.14, it looks like 0010-distinguish-XSI-compliant-strerror_r-from-GNU-specif.patch addresses bug #940130, and 0011-avoid-redefinition-of-prctl_mm_map-structure.patch addresses bug #939218.

Yamakuzure, maybe the ones for the corresponding version of elogind could be checked periodically, and applied upstream where appropriate?

[Xharlie]

⋮
Not if you install by way of plasma-meta.
If you pick and choose pieces ... maybe.
⋮

It's none of those. It's policykit that will thwart you:

`equery d elogind`:

Code: Select all

 * These packages depend on elogind:
dev-libs/libei-1.4.1 (elogind ? >=sys-auth/elogind-237)
                     (elogind ? >=sys-auth/elogind-237)
dev-libs/libratbag-0.18 (elogind ? sys-auth/elogind)
                        (elogind ? sys-auth/elogind)
media-video/pipewire-1.4.6 (elogind ? sys-auth/elogind)
                           (elogind ? sys-auth/elogind)
media-video/wireplumber-0.5.10 (elogind ? sys-auth/elogind)
                               (elogind ? sys-auth/elogind)
net-misc/networkmanager-1.48.16 (elogind ? >=sys-auth/elogind-219)
                                (elogind ? >=sys-auth/elogind-219)
sys-apps/accountsservice-23.13.9 (elogind ? >=sys-auth/elogind-229.4)
                                 (elogind ? >=sys-auth/elogind-229.4)
sys-apps/dbus-1.16.2 (elogind ? sys-auth/elogind)
                     (elogind ? sys-auth/elogind)
sys-auth/pambase-20250223 (elogind ? sys-auth/elogind[pam])
sys-auth/polkit-126-r1 (!systemd ? sys-auth/elogind)
                       (!systemd ? sys-auth/elogind)
sys-fs/udisks-2.10.1-r4 (elogind ? >=sys-auth/elogind-219)
                        (elogind ? >=sys-auth/elogind-219)
sys-libs/pam-1.7.1 (elogind ? >=sys-auth/elogind-254)
                   (elogind ? >=sys-auth/elogind-254)
sys-process/procps-4.0.5-r2 (elogind ? sys-auth/elogind)
                            (elogind ? sys-auth/elogind)

(That's from my developer-desktop that has been running and in active use pretty much 24/7 for over a year since my last serious overhaul.)

EDIT: What I mean to say is this: you could actually disable the requirement for `elogind` for everything except polkit.

So... no `polkit`? Maybe. I mean: I can always just `:w ! sudo tee blah blah wotevah` and forget about GUIs for anything that polkit might authorize. Maybe it does more than prompt for a password when you do sudo stuff? I don't actually know: it's one of those new-fangled never-needed-it-before Linux features that I just don't understand.