the path towards graphical user services and dbus-broker integration

[q66]

i have write down a bit of a plan to clarify how things are going to be done in the coming weeks; since these two are actually pretty tightly coupled together, i'm making a single issue for it

this is the high level overview of the steps:

• create an independent sd-event+sd-bus port (https://github.com/chimera-linux/tangle)
• set up user services infra in a way that provides the necessary targets (graphical.target, login.target chimera-linux/turnstile@d3ef9de)
• implement a way to trigger services through updates in activation environment (Implement listening on activation environment changes davmac314/dinit#388)
• complete the dinit protocol implementation in https://github.com/chimera-linux/libdinitctl, add api to create ephemeral units, and tag a release + package it (release still pending)
• make updates in dbus activation environment also update the dinit activation environment
• port dbus-broker's upstream systemd controller to tangle + libdinitctl
• patch elogind to force stop dinit graphical.target upon session changes from x11/wayland->tty as a temporary measure
• add graphical session tracking into turnstile + interface into dinit backend to properly stop graphical.target

[DONE] create an independent sd-event+sd-bus port

we now have https://github.com/chimera-linux/tangle which implements the complete api; it's also packaged in cports, so this is a prerequisite for dbus-broker controller port and other things

[DONE] set up user services infra in a way that provides the necessary targets

this is also done now, as turnstile since chimera-linux/turnstile@d3ef9de provides these, and all the existing user services have been updated; that means no more changes will be needed in them, and people can already trigger graphical.target themselves as a temporary hack while automatic system does not exist yet

[DONE] implement a way to trigger services through updates in activation environment

i have implemented this at protocol level in davmac314/dinit#388 and dinit-monitor can be used as a service driver to wait for some env vars to be available, which allows a barebones shell implementation of this to exist (a more proper implementation later will involve a specialized tool implemented with libdinitctl - but maybe not? either way if yes, libdinitctl will abstract away the socket touching and protocol parsing, which is a pain to do)

once the dinit-side stuff is in, we can effectively autotrigger graphical.target as soon as we see WAYLAND_DISPLAY and DISPLAY in that order; once done, it will still be necessary to manually update the dinit activation environment through dinitctl setenv, but doing so will automatically result in graphical.target becoming triggered, and permit graphical user services to start - of course, it does not handle stopping :) that is for later, but it does remove some of the manual work

we could even add a separate target only for x11, for potential graphical user services that require xwayland...

[DONE] complete the dinit protocol implementation in libdinitctl

currently the library is largely done, but some of the most recent protocol is not implemented; also, the new stuff in the PRs is also not implemented, so that needs to be implemented

while at it, i will add special api to create services via the library; these services will exist in the ephemeral namespace, so that you don't have to manually create the files - using this api will require root privileges for system dinit and user privileges for user dinit

libdinitctl also provides dinit-dbus, and dinit-dbus should expose these interfaces too, and that will be done

after that, i will need to tag a release and package it in the distro

make updates in dbus activation environment also update the dinit activation environment

dbus already does this for systemd, and we will want to do it too - any changes in dbus activation env should in turn issue a message to dinit-dbus (exposed by libdinitctl) to update dinit's activation env, assuming that dinit is present on the bus already

that will pretty much implement automatic triggering of graphical.target for most systems, as e.g. gnome-session already issues the UpdateActivationEnvironment message in dbus for WAYLAND_DISPLAY and DISPLAY, which will in turn update dinit, which will in turn result in the graphical.target being triggered

for desktops that do not update dbus, we will want to make them update dbus, otherwise dbus-spawned graphical stuff also does not work; also for desktops that do not require dbus (this is a very minor case though, because we kind of expect dbus to be present) we might also want to update the dinit env with these basic vars manually, but it's kinda whatever

of course, that still does not handle stopping the graphical.target, so that is still not the complete thing, but it means that users generally won't have to do much/anything...

it also means any other env vars that will be necessary for service-driven broker are present in dinit's environment at this point

port dbus-broker's upstream controller

writing a controller from scratch is a pain in the ass and we are much better off just using the same one as systemd, as that gets us policy parsing and all that stuff for free, and the systemd controller is not actually that much dependent on systemd - it relies on sd-bus and sd-event for its event loop and bus-talking, but we provide that via tangle; and of course, it talks to systemd dbus interfaces, but if we provide equivalent stuff in dinit-dbus we can fairly trivially change just that part of the code, and be all good

at that point, we will be able to replace our current dbus implementation with dbus-broker and be largely done with that part...

port elogind to stop graphical.target upon session changes

elogind currently tracks when a console session becomes graphical and the other way around; as long as we use elogind at all, it will be the thing that tracks this, so we will want to patch the code somewhat to issue a stop command to graphical.target (either by shelling out to dinitctl, or by invoking it via libdinitctl, either way is fine)

this mostly serves as a fallback - if the desktop session itself did not stop the target itself (which it should because these services should stop before the desktop fully stops), elogind will take care of properly cleaning up

at this point users of not-elogind will be a bit left out but that's fine for now; but for most users, it means the graphical user service stuff will be complete, including stopping - we will then want to add likely per-desktop ways to stop the graphical.target upon logout, elogind does not have any kind of "pre-stop" event which would be issued before the desktop shuts down (at least i am not aware of one), but it's not actually super important...

add graphical session tracking into turnstile

the current turnstile backend interface is a bit rudimentary, so it will likely grow a bunch with a few new commands/messages

we will need to implement the same functionality as elogind here, tracking when a session is graphical and the current type

in order to do that, we will need to effectively reimplement seatd inside turnstile, because we'll need a custom backend in libseat to get the session type from XDG_SESSION_TYPE that is set by the compositor; this information is completely discarded when using stock seatd

that's fine, because it's not actually that much code...

these paths will be used for now for people who don't use elogind; they can be early testers for the functionality while elogind is being phased out

once elogind is phased out, this path will become the default, and it should all be complete

expected timeframe

everything up until the broker port should be done within the next ~2 weeks

the rest i am not sure, depends on how much unexpected trouble it will put in my way, but the complete thing will probably happen before end of the year

in any case it means users will incrementally start seeing more and more of the functionality and the "complete" solution does not necessarily hold back having at least some of it already