Bringing forth runit integration regarding desktop environments

[Martin Steigerwald]

Hi Andrew.

Thank you!

Andrew Bower - 09.11.24, 20:42:55 MEZ:
> > However I wonder about doing some work for desktop integration as
> > well.
> 
> I wonder how much time (or more importantly, upload cycles) we have to
> get improvements to runit viability into Trixie and what the highest
> priority gaps are that could use help?

Yeah, I am not sure about whether we can get it into Trixie. I need to be 
careful not to overload myself as I am aware others need to be as well 
given the busy life's most of us live. But I'd start anyway. It will be 
ready, when it will be ready.

> > And again I also wondered about pipewire integration as well. AFAIR
> > according to some discussion about it this cannot really be handled as
> > a system service, but needs to be tied to the user session, probably
> > by DBUS activation.
> > 
> > Maybe what Alpine does there would be a good approach:
> > 
> > https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/p
> > ipewire/pipewire-launcher.sh
> > 
> > I believe I read from a Devuan user that this would work. But I did
> > not
> > find that mail anymore. So I am not completely sure where to integrate
> > Pipewire startup properly.
> 
> Are you thinking of something from this thread?
> 
> https://dev1galaxy.org/viewtopic.php?id=5867

Yeah, maybe it was this forum thread. Thanks for digging it out.

I did not see a generic solution in there though. Best would be init 
system agnostic *and* working with both X11 and Wayland in different 
desktop environments. Maybe that is not really workable, see below for 
some questions about it.

> Following inspiration from there I went with a user runsvdir supervision
> tree started by an XFCE application launcher. There are three pipewire
> services that get started and log within the user's directory. This
> worked well and got torn down on session exit:
> 
> https://dev1galaxy.org/viewtopic.php?pid=49574#p49574
> 
> However, it's a toy solution, not a proper one.

Well I thought along the lines of what you did in

https://github.com/andy-bower/runit-desktop

as well for other user services that were needed for a while but are not 
needed anymore:

https://git.devuan.org/martin/user-services/

I am not really happy with the approach I have taken there even though it 
has some usability and basically worked for me. My current approach only 
works with a Plasma session. It could easily be extended for .xsessionrc, 
but then it would only work with X11 and not Wayland. Also it would be 
great to be able to reuse the existing runit commands instead of my new 
"userservice" "command".

All of this brings me to three questions:

1) Whether an init agnostic approach is actually workable for Pipewire? 
Runit user services would work if done properly, also for quitting 
Pipewire with the session. Stuff like this could indeed go into some
runit-desktop package :)

2) How to do Runit user services properly? You mentioned Lorenzo is 
thinking about this for a while.

3) If an init agnostic approach is not possible, how to do it for other 
inits? I'd focus on Runit anyway, if no init agnostic approach is 
possible, as I need to focus in order to get something accomplished.

I'd assume installing an Alpine based desktop and an Void Linux based 
desktop may help to reveal exactly how they did it and whether it works 
with both X11 and Wayland and maybe different desktop environments. That 
may be something I am going to explore as one of my next steps.

Alpine uses OpenRC and Void Linux Runit… so looking at both may give an 
idea on whether init agnostic *and* generic is realistic. They have it 
easier… cause they just decided on one init to support properly.

> I'm afraid I don't know anything about dbus, login/seat/session
> management or X session manager plumbing but a runit supervision tree
> for users mapped to one of these entities would be appealing. (I don't
> know if the systemd solution even uses correct mapping - does it work if
> you have multiple 'heads' on your machine? Maybe no one cares!) On the
> other hand, your X session manager already exercises a process
> supervision role so is it really right to layer another one on top?

All valid questions. I hope that Mark, Lorenzo and others will give their 
ideas and insights.

> I wonder what ideas Lorenzo has up his sleeve for a general solution to
> user runit supervision?

As do I! :)

Best,
-- 
Martin