You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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 (ca7ccc5)
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
[DONE] 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
The text was updated successfully, but these errors were encountered:
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:
graphical.target
,login.target
chimera-linux/turnstile@d3ef9de)graphical.target
upon session changes from x11/wayland->tty as a temporary measure[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 withlibdinitctl
- 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 seeWAYLAND_DISPLAY
andDISPLAY
in that order; once done, it will still be necessary to manually update the dinit activation environment throughdinitctl setenv
, but doing so will automatically result ingraphical.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 workwe 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 providesdinit-dbus
, anddinit-dbus
should expose these interfaces too, and that will be doneafter that, i will need to tag a release and package it in the distro
[DONE] 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 bylibdinitctl
) to update dinit's activation env, assuming that dinit is present on the bus alreadythat will pretty much implement automatic triggering of
graphical.target
for most systems, as e.g.gnome-session
already issues theUpdateActivationEnvironment
message in dbus forWAYLAND_DISPLAY
andDISPLAY
, which will in turn update dinit, which will in turn result in thegraphical.target
being triggeredfor 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
andsd-event
for its event loop and bus-talking, but we provide that viatangle
; and of course, it talks to systemd dbus interfaces, but if we provide equivalent stuff indinit-dbus
we can fairly trivially change just that part of the code, and be all goodat 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 inlibseat
to get the session type fromXDG_SESSION_TYPE
that is set by the compositor; this information is completely discarded when using stockseatd
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 whileelogind
is being phased outonce
elogind
is phased out, this path will become the default, and it should all be completeexpected 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
The text was updated successfully, but these errors were encountered: