Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

elogind replacement #19

Open
alarixnia opened this issue Aug 3, 2021 · 4 comments
Open

elogind replacement #19

alarixnia opened this issue Aug 3, 2021 · 4 comments

Comments

@alarixnia
Copy link

Inquiring minds want to know whether a standalone library implementing the bits of logind GNOME/KDE want to have is part of the roadmap.

@netbsduser
Copy link
Member

InitWare has a logind (inherited from systemd) which I ported, to some extent, to NetBSD along with FreeBSD. But the parts of interest to desktop environments (seat management etc) are not working right, though. That part of the codebase of logind is written in a very Linux-specific way.
Making this work on e.g. NetBSD is not a trivial undertaking, though it shouldn't a terribly complicated undertaking either. will look into it at some point and figure out what work would need to be done for it to work
It may be the case that implementing a new logind-compatible daemon would be the easier choice here. I also think that a libudev-compatible interface to /dev/drvctl would be very handy. FreeBSD's libdevd-udev and DragonFly BSD's libdevattr both demonstate udev-compatible interfaces to their respective platforms' device enumeration and events systems.

@valpackett
Copy link
Contributor

It may be the case that implementing a new logind-compatible daemon would be the easier choice here

I am "planning" to implement login1 in Rust for FreeBSD as part of https://github.com/DankBSD/complexd (currently I only have a hostname1 implementation there). Someday it'll be a thing maybe :)

There's also good old ConsoleKit2 (& my fork that fixes drm support on FreeBSD) — being the direct predecessor of logind, it has a very similar API on the D-Bus. In fact KDE's KWin still does support it. Might be an option to update CK2 to the new (login1) API. Call it CK3? :D

On the other hand since there is a ported logind here… changes could be made similar to my CK2 changes to make it all work for desktop environments? What exactly is not working right?

@netbsduser
Copy link
Member

It's some time ago that I last played with it - but some issues I can remember it having on NetBSD is that it doesn't know how to enumerate devices (DRM, inputs, etc), it doesn't know how to tell the current VT and when a VT is changed, and it doesn't know on which vt you are trying to login (on Linux it does a "semi-ugly" thing which didn't seem to work on NetBSD:)

/* We deduce the X11 socket from the display name, then use
* SO_PEERCRED to determine the X11 server process, ask for
* the controlling tty of that and if it's a VC then we know
* the seat and the virtual terminal. Sounds ugly, is only
* semi-ugly. */

I think Kenny Levinsen's seatd and libseat are also interesting entrants to this market; libseat (a seat management library which can work with either a logind or seatd backend; maybe more backends could appear) already commands an impressive share of the Wayland compositor market, and I think it's even used by WL-Roots, which is a popular framework for building Wayland compositors with.

@florhizome
Copy link

Hey,
I've been looking a bit at the session-manager/init situation. being on GNU Guix, and intending to stay there, it would be nice to have an alternative to to elogind i think, that's not so linux specific (guix supports the hurd, too ;D and generally uses the shepherd for init. so supporting further unixes could be a sometimes flaunted idea in #guix). I built ck2 but so far I haven't had success with libnih which seems to be needed for it's cgroup capabilities, but it's all just very old.... initware's approach seems much more attractive for guix :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants