Possible session-environment issue when starting Wayfire from a TTY

[birdie-github]

I'm running Wayfire 0.11 on Fedora 44, started directly from a TTY rather than through a graphical display manager.

I ran into an issue with applications activated through the user's D-Bus session. For example, blueman-applet works and its StatusNotifierItem appears in wf-panel, but activating blueman-manager from the tray fails with:

GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected

After some debugging, I found that in a fresh Wayfire session:

$ echo "$WAYLAND_DISPLAY"
wayland-1

$ systemctl --user show-environment | grep WAYLAND_DISPLAY
# nothing

and the D-Bus activation environment likewise does not contain WAYLAND_DISPLAY.

Running:

dbus-update-activation-environment --systemd \
    WAYLAND_DISPLAY DISPLAY XAUTHORITY

immediately fixes the problem; blueman-manager can then be activated normally from the tray.

I noticed that Wayfire's example configuration already contains this command, so perhaps this is expected when launching Wayfire directly from a TTY.

I'm mainly wondering whether this is considered normal session setup, or whether Wayfire should perhaps establish/import the graphical session environment automatically when started from a TTY. I'm not very familiar with the intended Wayland/systemd/D-Bus session model, so I wanted to ask before assuming this is a Wayfire bug.

Environment: Fedora 44, Wayfire 0.11. No graphical login manager. Started from a TTY.

[dkondor]

Hi,

See also (in case you have not seen them yet):
https://github.com/WayfireWM/wayfire/wiki/Tips-&-Tricks#gtk3-applications-slow-startup-or-desktop-files-not-opening
#775

In theory, Wayfire could do this automatically, but that would be problematic in a nested session (currently, the user has the option to run a nested instance with a config file that does not contain this command). E.g. labwc does this automatically, but only if it is running with the drm backend, so in nested sessions it will be skipped:
https://github.com/labwc/labwc/blob/6e461d8399eb9935f77c47bba2c939d5e58289ca/src/config/session.c#L193

Another complication is that if Wayfire is run as a systemd unit with type "notify" that is required for scheduling the start of dependent units (e.g. https://github.com/dkondor/cairo-dock-wayland-session/blob/main/systemd/cd-session-wayfire.service) then systemd-notify --ready should be also called, but only after the env vars have been correctly set. This can be done by the following variation in the config:

[autostart]
00_dbus = dbus-update-activation-environment WAYLAND_DISPLAY DISPLAY XAUTHORITY WAYFIRE_SOCKET
01_systemd = /bin/sh -c "systemctl --user import-environment WAYLAND_DISPLAY DISPLAY XAUTHORITY WAYFIRE_SOCKET && systemd-notify --ready"

See also #3052 why this might be necessary.

It could be nice if Wayfire could auto-detect these kinds of things and do the correct thing, but this will get quite complicated (e.g. I don't know if there is a reliable way to check if it is being run as a systemd service). So the best option might be to leave this to DE developers and / or packagers (or users if not using a DE).