GNU bug report logs - #76619
[PATCH] gnu: home: services: Add 'wayland-display' service.

Previous Next

To reply to this bug, email your comments to 76619 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sisiutl <sisiutl <at> egregore.fun>
To: guix-patches <at> gnu.org
Cc: Sisiutl <sisiutl <at> egregore.fun>
Subject: [PATCH] gnu: home: services: Add 'wayland-display' service.
Date: Thu, 27 Feb 2025 23:46:20 +0100

* gnu/home/services/desktop.scm (wayland-shepherd-service): New procedure.
(home-wayland-service-type): New variable.
* doc/guix.texi (Desktop Home Services): Document it.

Change-Id: If1ed849d29198d2949c6852b0f2645e325211240
---
 doc/guix.texi                 | 36 +++++++++++++++++++
 gnu/home/services/desktop.scm | 66 +++++++++++++++++++++++++++++++++++
 2 files changed, 102 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index bb5f29277f..36b86cffe1 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -47839,6 +47839,42 @@ In the example above, @code{x11-display} is instructed to set
 @env{DISPLAY} to @code{:3}.
 @end defvar
 
+@defvar home-wayland-service-type
+This is the service type representing a Wayland compositor.  It
+functions as an equivalent of @code{x11-service-type} for Wayland.
+
+Like X11, Wayland compositors are started by services like
+@code{gdm-service-type}, described in the system configuration.  At the
+level of Guix Home, as an unprivileged user, we cannot start our Wayland
+compositor; all we can do is check whether it is running.   This is what
+this service does.
+
+As a user, you probably don't need to worry or explicitly instantiate
+@code{home-wayland-service-type}.  Services that require an Wayland
+graphical display instantiate this service and depend on its
+corresponding @code{wayland-display} Shepherd service (@pxref{Shepherd
+Home Service}).
+
+If you're writing a Shepherd service that requires the presence of a
+Wayland compositor, you need to depend on this service to ensure Wayland
+is accessible from your service.
+
+When the Wayland compositor is running, the @code{wayland-display}
+Shepherd service starts and sets the @env{WAYLAND_DISPLAY} environment
+variable of the @command{shepherd} process, using its original value if
+it was already set; otherwise, it fails to start.
+
+The service can also be forced to use a given value for
+@env{WAYLAND_DISPLAY}, like so:
+
+@example
+herd start wayland-display wayland-2
+@end example
+
+In the example above, @code{wayland-display} is instructed to set
+@env{WAYLAND_DISPLAY} to @code{wayland-2}.
+@end defvar
+
 @defvar home-redshift-service-type
 This is the service type for @uref{https://github.com/jonls/redshift,
 Redshift}, a program that adjusts the display color temperature
diff --git a/gnu/home/services/desktop.scm b/gnu/home/services/desktop.scm
index fc96ce9295..88bc871adb 100644
--- a/gnu/home/services/desktop.scm
+++ b/gnu/home/services/desktop.scm
@@ -33,6 +33,8 @@ (define-module (gnu home services desktop)
   #:use-module (ice-9 match)
   #:export (home-x11-service-type
 
+            home-wayland-service-type
+
             home-redshift-configuration
             home-redshift-configuration?
             home-redshift-service-type
@@ -121,6 +123,70 @@ (define home-x11-service-type
 during that time, the @code{x11-display} service is marked as failing to
 start.")))
 
+
+;;;
+;;; Waiting for Wayland.
+;;;
+
+(define (wayland-shepherd-service config)
+  (list (shepherd-service
+         (provision '(wayland-display))
+         (modules '((ice-9 ftw)
+                    (ice-9 regex)
+                    (ice-9 match)
+                    (srfi srfi-1)
+                    (shepherd support)))
+         (respawn? #t)
+         (respawn-limit config)
+         (respawn-delay 1)
+         (start
+          #~(lambda* (#:optional (env-wayland-display (getenv "WAYLAND_DISPLAY")))
+
+              (define wayland-socket-regex "wayland-[0-9]+$")
+
+              (define (find-socket directory regex)
+                (find (match-lambda
+                        ((or "." "..") #f)
+                        (name
+                         (let ((name (in-vicinity directory
+                                                  name)))
+                           (and (string-match regex name)
+                                (access? name O_RDWR)))))
+                      ;; Wayland names its sockets ‘wayland-n’. With
+                      ;; ‘reverse’, we pick up on the last Wayland instance
+                      ;; created (essentially what we always want to do).
+                      (or (reverse (scandir directory)) '())))
+
+              (define wayland-display
+                (or env-wayland-display
+                    (find-socket %user-runtime-dir "wayland-[0-9]+$")))
+
+              (when wayland-display
+                (format #t "Wayland display found at ~s.~%" wayland-display)
+                ;; Note: 'make-forkexec-constructor' calls take their
+                ;; default #:environment-variables value before this service
+                ;; is started and are thus unaffected by the 'setenv' call
+                ;; below.  Users of this service have to explicitly query
+                ;; its value.
+                (setenv "WAYLAND_DISPLAY" wayland-display))
+              wayland-display))
+         (stop #~(lambda (_)
+                   (unsetenv "WAYLAND_DISPLAY")
+                   #f)))))
+
+(define home-wayland-service-type
+  (service-type
+   (name 'home-wayland-display)
+   (extensions (list (service-extension home-shepherd-service-type
+                                        wayland-shepherd-service)))
+   (default-value 10)
+   (description
+    "Create a @code{wayland-display} Shepherd service that waits for a Wayland
+compositor to be up and running, up to a configurable delay, and sets the
+@code{WAYLAND_DISPLAY} environment variable of @command{shepherd} itself
+accordingly.  If no accessible Wayland server shows up during that time, the
+@code{wayland-display} service is marked as failing to start.")))
+
 
 ;;;
 ;;; Redshift.
-- 
2.48.1

Message #8 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Sisiutl <sisiutl <at> egregore.fun>
Cc: 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Fri, 28 Feb 2025 23:02:07 +0100

Hello,

Sisiutl <sisiutl <at> egregore.fun> skribis:

> * gnu/home/services/desktop.scm (wayland-shepherd-service): New procedure.
> (home-wayland-service-type): New variable.
> * doc/guix.texi (Desktop Home Services): Document it.
>
> Change-Id: If1ed849d29198d2949c6852b0f2645e325211240

Nice!  So this is a followup to <https://issues.guix.gnu.org/76060>.


[...]

> +(define (wayland-shepherd-service config)
> +  (list (shepherd-service
> +         (provision '(wayland-display))
> +         (modules '((ice-9 ftw)
> +                    (ice-9 regex)
> +                    (ice-9 match)
> +                    (srfi srfi-1)
> +                    (shepherd support)))
> +         (respawn? #t)
> +         (respawn-limit config)
> +         (respawn-delay 1)

The default value for ‘config’ is 10, but that’s not a valid value for
‘respawn-limit’ (it should be a pair).

But anyway, we should remove these two fields: they have no effect,
except for services associated with a process.  We can also change
‘default-value’ to #f or so to not give the impression that it has a
special meaning.

Apart from that LGTM; let me know if you can make this change (and if it
sounds right to you) or I can do it on your behalf.

Thanks,
Ludo’.

Message #13 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Sisiutl <sisiutl <at> egregore.fun>, 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Sun, 02 Mar 2025 13:10:15 +0800

Hi Sisiutl and Ludo,

I merged all wayland-display issues, please send follow-ups to
ISSUE_NUMBER <at> debbugs.gnu.org instead of guix-patches <at> gnu.org next time :)

On Sat, 01 Mar 2025 06:02:07 +0800,
Ludovic Courtès wrote:
>
> Hello,
>
> Sisiutl <sisiutl <at> egregore.fun> skribis:
>
> > * gnu/home/services/desktop.scm (wayland-shepherd-service): New procedure.
> > (home-wayland-service-type): New variable.
> > * doc/guix.texi (Desktop Home Services): Document it.
> >
> > Change-Id: If1ed849d29198d2949c6852b0f2645e325211240
>
> Nice!  So this is a followup to <https://issues.guix.gnu.org/76060>.
>
>
> [...]
>
> > +(define (wayland-shepherd-service config)
> > +  (list (shepherd-service
> > +         (provision '(wayland-display))
> > +         (modules '((ice-9 ftw)
> > +                    (ice-9 regex)
> > +                    (ice-9 match)
> > +                    (srfi srfi-1)
> > +                    (shepherd support)))
> > +         (respawn? #t)
> > +         (respawn-limit config)
> > +         (respawn-delay 1)
>
> The default value for ‘config’ is 10, but that’s not a valid value for
> ‘respawn-limit’ (it should be a pair).
>
> But anyway, we should remove these two fields: they have no effect,
> except for services associated with a process.  We can also change
> ‘default-value’ to #f or so to not give the impression that it has a
> special meaning.
>
> Apart from that LGTM; let me know if you can make this change (and if it
> sounds right to you) or I can do it on your behalf.

Since some services may depend on either DISPLAY or WAYLAND_DISPLAY, and these
two services (x11-display, wayland-display) are similar, I think we can merge
them into one and deprecate home-x11-service-type by this new service.

e.g.
--8<---------------cut here---------------start------------->8---
service: home-display-service-type
configuration: x11? (boolean: #f) wayland? (boolean: #f) time-to-wait (integer: 10)
default-value #f
provision: 'x11-display when x11? is #t
           'wayland-display when walyand? is #t
           'display when either x11? or wayland? is #t
return value: "DISPLAY: unset; WAYLAND_DISPLAY: wayland-1"
--8<---------------cut here---------------end--------------->8---

Then one service can choose to depend on 'display or specifically 'x11-display /
'wayland-display.

Message #16 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Hilton Chain <hako <at> ultrarare.space>
Cc: Sisiutl <sisiutl <at> egregore.fun>, 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Wed, 05 Mar 2025 16:16:18 +0100

Hi Hilton,

Hilton Chain <hako <at> ultrarare.space> skribis:

> Since some services may depend on either DISPLAY or WAYLAND_DISPLAY, and these
> two services (x11-display, wayland-display) are similar, I think we can merge
> them into one and deprecate home-x11-service-type by this new service.
>
> e.g.
>
> service: home-display-service-type
> configuration: x11? (boolean: #f) wayland? (boolean: #f) time-to-wait (integer: 10)
> default-value #f
> provision: 'x11-display when x11? is #t
>            'wayland-display when walyand? is #t
>            'display when either x11? or wayland? is #t
> return value: "DISPLAY: unset; WAYLAND_DISPLAY: wayland-1"
>
> Then one service can choose to depend on 'display or specifically 'x11-display /
> 'wayland-display.

That sounds like a good idea to me.  It goes beyond the scope of the
initial patch in this thread though.

Sisiutl, Hilton: who wants to work on it?

Thanks,
Ludo’.

Message #19 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Sisiutl <sisiutl <at> egregore.fun>, 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Fri, 07 Mar 2025 23:48:24 +0800

On Wed, 05 Mar 2025 23:16:18 +0800,
Ludovic Courtès wrote:
>
> Hi Hilton,
>
> Hilton Chain <hako <at> ultrarare.space> skribis:
>
> > Since some services may depend on either DISPLAY or WAYLAND_DISPLAY, and these
> > two services (x11-display, wayland-display) are similar, I think we can merge
> > them into one and deprecate home-x11-service-type by this new service.
> >
> > e.g.
> >
> > service: home-display-service-type
> > configuration: x11? (boolean: #f) wayland? (boolean: #f) time-to-wait (integer: 10)
> > default-value #f
> > provision: 'x11-display when x11? is #t
> >            'wayland-display when walyand? is #t
> >            'display when either x11? or wayland? is #t
> > return value: "DISPLAY: unset; WAYLAND_DISPLAY: wayland-1"
> >
> > Then one service can choose to depend on 'display or specifically 'x11-display /
> > 'wayland-display.
>
> That sounds like a good idea to me.  It goes beyond the scope of the
> initial patch in this thread though.
>
> Sisiutl, Hilton: who wants to work on it?

Sure, I can do this.  I'll begin in a few days.

Message #22 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Sisiutl <sisiutl <at> egregore.fun>, 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Mon, 10 Mar 2025 19:20:32 +0800

On Fri, 07 Mar 2025 23:48:24 +0800,
Hilton Chain wrote:
>
> On Wed, 05 Mar 2025 23:16:18 +0800,
> Ludovic Courtès wrote:
> >
> > Hi Hilton,
> >
> > Hilton Chain <hako <at> ultrarare.space> skribis:
> >
> > > Since some services may depend on either DISPLAY or WAYLAND_DISPLAY, and these
> > > two services (x11-display, wayland-display) are similar, I think we can merge
> > > them into one and deprecate home-x11-service-type by this new service.
> > >
> > > e.g.
> > >
> > > service: home-display-service-type
> > > configuration: x11? (boolean: #f) wayland? (boolean: #f) time-to-wait (integer: 10)
> > > default-value #f
> > > provision: 'x11-display when x11? is #t
> > >            'wayland-display when walyand? is #t
> > >            'display when either x11? or wayland? is #t
> > > return value: "DISPLAY: unset; WAYLAND_DISPLAY: wayland-1"
> > >
> > > Then one service can choose to depend on 'display or specifically 'x11-display /
> > > 'wayland-display.
> >
> > That sounds like a good idea to me.  It goes beyond the scope of the
> > initial patch in this thread though.
> >
> > Sisiutl, Hilton: who wants to work on it?
>
> Sure, I can do this.  I'll begin in a few days.

On a second thought ‘display’ may not be a good name, I'm going to use
‘graphical-session’, sounds familiar? ;)

I have realized that for a Wayland session, setting only ‘WAYLAND_DISPLAY’ in
Shepherd is not sufficient to make all applications work.

Currently to have a fully-functional setup, you'll need to disable auto starting
of ‘home-shepherd-service-type’ and start Shepherd via Wayland compositor to
have all needed environment variables passed to Shepherd.  This patch doesn't
make a difference in this regard.

To address this, I have made the service to accpet passing environment variables
directly:
--8<---------------cut here---------------start------------->8---
herd start graphical-session \
    DISPLAY=$DISPLAY \
    WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
    XDG_SESSION_TYPE=$XDG_SESSION_TYPE \
    XDG_CURRENT_DESKTOP=$XDG_CURRENT_DESKTOP \
    NIRI_SOCKET=$NIRI_SOCKET
--8<---------------cut here---------------end--------------->8---

These environment variables will be collected in ‘GUIX_GRAPHICAL_SESSION’:
--8<---------------cut here---------------start------------->8---
GUIX_GRAPHICAL_SESSION => "DISPLAY WALYAND_DISPLAY XDG_SESSION_TYPE ..."
--8<---------------cut here---------------end--------------->8---

And used by users of ‘graphical-session’:
--8<---------------cut here---------------start------------->8---
#:environment-variables
(let ((update-environment-variable
       (lambda (name base)
         (match (getenv name)
           (#f base)
           (value (cons (string-append name "=" value)
                        (remove (cut string-prefix?
                                     (string-append name "=")
                                     <>)
                                base)))))))
  (fold update-environment-variable
        (default-environment-variables)
        (or (and=> (getenv "GUIX_GRAPHICAL_SESSION")
                   string-tokenize)
            '("DISPLAY" "WAYLAND_DISPLAY"))))
--8<---------------cut here---------------end--------------->8---

However I found that Shepherd starts ‘graphical-session’ even if its
auto-starting is disabled, when there're services depending on it.

Is this intended?  I expect to have these services waiting ‘graphical-session’
to start instead of starting it right away.

Message #25 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Hilton Chain <hako <at> ultrarare.space>
Cc: Sisiutl <sisiutl <at> egregore.fun>, 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Mon, 10 Mar 2025 22:16:36 +0100

Hi!

Hilton Chain <hako <at> ultrarare.space> skribis:

> On a second thought ‘display’ may not be a good name, I'm going to use
> ‘graphical-session’, sounds familiar? ;)

Good idea.  :-)

> I have realized that for a Wayland session, setting only ‘WAYLAND_DISPLAY’ in
> Shepherd is not sufficient to make all applications work.

The goal of ‘x11-display’ now is only to (1) ensure X11 is running, and
(2) determine the correct value of ‘DISPLAY’ so other services can use
it.

I would say that other environment variables like the Freedesktop ones
(XDG_*) are beyond the scope of such a service.  WDYT?

> herd start graphical-session \
>     DISPLAY=$DISPLAY \
>     WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
>     XDG_SESSION_TYPE=$XDG_SESSION_TYPE \
>     XDG_CURRENT_DESKTOP=$XDG_CURRENT_DESKTOP \
>     NIRI_SOCKET=$NIRI_SOCKET
>
>
> These environment variables will be collected in ‘GUIX_GRAPHICAL_SESSION’:

That seems a bit too complex to me.

> However I found that Shepherd starts ‘graphical-session’ even if its
> auto-starting is disabled, when there're services depending on it.

That’s not really intended, but it’s a Guix issue, not a Shepherd issue
(the Shepherd has no notion of “auto starting”; it just starts whatever
you ask it to start in your config file).

Perhaps the ‘auto-start?’ property should automatically propagate along
edges?

Thanks,
Ludo’.

Message #28 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Sisiutl <sisiutl <at> egregore.fun>, 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Tue, 11 Mar 2025 22:39:59 +0800

On Tue, 11 Mar 2025 05:16:36 +0800,
Ludovic Courtès wrote:
>
> Hi!
>
> Hilton Chain <hako <at> ultrarare.space> skribis:
>
> > On a second thought ‘display’ may not be a good name, I'm going to use
> > ‘graphical-session’, sounds familiar? ;)
>
> Good idea.  :-)
>
> > I have realized that for a Wayland session, setting only ‘WAYLAND_DISPLAY’ in
> > Shepherd is not sufficient to make all applications work.
>
> The goal of ‘x11-display’ now is only to (1) ensure X11 is running, and
> (2) determine the correct value of ‘DISPLAY’ so other services can use
> it.
>
> I would say that other environment variables like the Freedesktop ones
> (XDG_*) are beyond the scope of such a service.  WDYT?
>
> > herd start graphical-session \
> >     DISPLAY=$DISPLAY \
> >     WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
> >     XDG_SESSION_TYPE=$XDG_SESSION_TYPE \
> >     XDG_CURRENT_DESKTOP=$XDG_CURRENT_DESKTOP \
> >     NIRI_SOCKET=$NIRI_SOCKET
> >
> >
> > These environment variables will be collected in ‘GUIX_GRAPHICAL_SESSION’:
>
> That seems a bit too complex to me.

I finally realized...!  ‘x11-display’ has a fundamental issue: It actually
relies on pre-existing graphical session!

1. Shepherd loads service definitons
  - 'service' dependending on ‘x11-display’ calls ‘(getenv "DISPLAY")’ in its
    definiton -> it depends on existing DISPLAY.
  - Shepherd actually fails at this stage if there's no pre-existing DISPLAY.
2. Shepherd starts ‘x11-display’
  - ‘x11-display’ finds socket and sets DISPLAY.
3. Shepherd starts 'service'
  - 'service' is already loaded in (1.), DISPLAY set in (2.) won't affect it.

Bad news, but simplifies the whole thing a lot :)

We can just remove socket finding part from ‘x11-display’ and use ‘getenv’
instead.  Then For a ‘graphical-session’ provision, Shepherd should be started
by... a graphical session.  Previously for ‘x11-display’ I think Shepherd was
supposed to be started by a display manager, but I'm not sure if WAYLAND_DISPLAY
changes when using a display manager.

home-shepherd-service-type doesn't set default environment variables so
Shepherd's starting environment is inherited.  Then no need to worry about
importing environment variables if we want to keep this behavior.

So a graphical session setup is what I have mentioned before: Disable
auto-starting of Shepherd, and start it in your desktop environment.

I'm using this snippet btw:
--8<---------------cut here---------------start------------->8---
pgrep --uid $USER shepherd > /dev/null || shepherd
--8<---------------cut here---------------end--------------->8---

> > However I found that Shepherd starts ‘graphical-session’ even if its
> > auto-starting is disabled, when there're services depending on it.
>
> That’s not really intended, but it’s a Guix issue, not a Shepherd issue
> (the Shepherd has no notion of “auto starting”; it just starts whatever
> you ask it to start in your config file).
>
> Perhaps the ‘auto-start?’ property should automatically propagate along
> edges?

Either services marked not to auto-start starting or those marked as auto-start
not starting? :P  I'm not sure which side to choose.

For the specific case this is unnecessary now, as there's no need to wait to
import environment variables.

Message #31 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Sören Tempel <soeren <at> soeren-tempel.net>
To: 76619 <at> debbugs.gnu.org
Cc: Hilton Chain <hako <at> ultrarare.space>
Subject: [PATCH] gnu: home: services: Add 'wayland-display' service.
Date: Fri, 11 Jul 2025 20:55:41 +0200

Hi!

I was just looking into having my wayland-dependent services supervised
by the Shepherd and come across this issue.

Hilton Chain <hako <at> ultrarare.space> wrote:
> Currently to have a fully-functional setup, you'll need to disable
> auto starting of ‘home-shepherd-service-type’ and start Shepherd via
> Wayland compositor to have all needed environment variables passed to
> Shepherd.

Is that still the best way to achieve this? If so: How do I do that? Of
cause I can patch home-shepherd-service-type in the monorepo and change
the default value of the `auto-start?` property, but is there a better
way which doesn't require me doing that? Should we maybe also document
this in the manual?

Greetings
Sören

Message #34 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Sören Tempel <soeren <at> soeren-tempel.net>
Cc: 76619 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: home: services: Add 'wayland-display' service.
Date: Sat, 12 Jul 2025 19:59:38 +0800

Sören Tempel <soeren <at> soeren-tempel.net> writes:

> Hi!
>
> I was just looking into having my wayland-dependent services supervised
> by the Shepherd and come across this issue.
>
> Hilton Chain <hako <at> ultrarare.space> wrote:
>> Currently to have a fully-functional setup, you'll need to disable
>> auto starting of ‘home-shepherd-service-type’ and start Shepherd via
>> Wayland compositor to have all needed environment variables passed to
>> Shepherd.
>
> Is that still the best way to achieve this? If so: How do I do that? Of
> cause I can patch home-shepherd-service-type in the monorepo and change
> the default value of the `auto-start?` property, but is there a better
> way which doesn't require me doing that? Should we maybe also document
> this in the manual?

You can add 'home-shepherd-service-type' service and configure it, its
configuration is actually documented[1].

I have described my setup in [2].  To document it, I think we need to find a
reliable way to start Shepherd first.

Thanks

[1]: https://guix.gnu.org/manual/devel/en/html_node/Shepherd-Home-Service.html
[2]: https://lists.gnu.org/archive/html/guix-devel/2025-06/msg00285.html

Message #37 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Hilton Chain <hako <at> ultrarare.space>
Cc: Sisiutl <sisiutl <at> egregore.fun>,
 Ludovic Courtès <ludo <at> gnu.org>, 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Fri, 22 Aug 2025 14:14:52 +0200

Hi,

What is the status of this patch

    https://issues.guix.gnu.org/issue/76619

?

On Tue, 11 Mar 2025 at 22:39, Hilton Chain <hako <at> ultrarare.space> wrote:

> I finally realized...!  ‘x11-display’ has a fundamental issue: It actually
> relies on pre-existing graphical session!
>
> 1. Shepherd loads service definitons
>   - 'service' dependending on ‘x11-display’ calls ‘(getenv "DISPLAY")’ in its
>     definiton -> it depends on existing DISPLAY.
>   - Shepherd actually fails at this stage if there's no pre-existing DISPLAY.
> 2. Shepherd starts ‘x11-display’
>   - ‘x11-display’ finds socket and sets DISPLAY.
> 3. Shepherd starts 'service'
>   - 'service' is already loaded in (1.), DISPLAY set in (2.) won't affect it.
>
> Bad news, but simplifies the whole thing a lot :)
>
> We can just remove socket finding part from ‘x11-display’ and use ‘getenv’
> instead.  Then For a ‘graphical-session’ provision, Shepherd should be started
> by... a graphical session.  Previously for ‘x11-display’ I think Shepherd was
> supposed to be started by a display manager, but I'm not sure if WAYLAND_DISPLAY
> changes when using a display manager.
>
> home-shepherd-service-type doesn't set default environment variables so
> Shepherd's starting environment is inherited.  Then no need to worry about
> importing environment variables if we want to keep this behavior.
>
> So a graphical session setup is what I have mentioned before: Disable
> auto-starting of Shepherd, and start it in your desktop environment.
>
> I'm using this snippet btw:
>
> pgrep --uid $USER shepherd > /dev/null || shepherd

[...]

> Either services marked not to auto-start starting or those marked as auto-start
> not starting? :P  I'm not sure which side to choose.
>
> For the specific case this is unnecessary now, as there's no need to wait to
> import environment variables.


Cheers,
simon

Message #40 received at 76619 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: Sisiutl <sisiutl <at> egregore.fun>,
 Ludovic Courtès <ludo <at> gnu.org>, 76619 <at> debbugs.gnu.org
Subject: Re: [bug#76619] [PATCH] gnu: home: services: Add 'wayland-display'
 service.
Date: Sat, 23 Aug 2025 12:38:04 +0800

Simon Tournier <zimon.toutoune <at> gmail.com> writes:

> Hi,
>
> What is the status of this patch
>
>     https://issues.guix.gnu.org/issue/76619
>
> ?

I have an implementation here but haven't managed to finish it for
upstreaming.

https://git.boiledscript.com/hako/guix/commit/9d1e164a578ff7e21c09d703a9ea243434894dd9

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.