32 lines
1.7 KiB
Text
32 lines
1.7 KiB
Text
|
# Address several issues with DBus activation and systemd user sessions
|
||
|
#
|
||
|
# 1. DBus-activated and systemd services do not share the environment with user
|
||
|
# login session. In order to make the applications that have GUI or interact
|
||
|
# with the compositor work as a systemd user service, certain variables must
|
||
|
# be propagated to the systemd and dbus.
|
||
|
# Possible (but not exhaustive) list of variables:
|
||
|
# - DISPLAY - for X11 applications that are started as user session services
|
||
|
# - WAYLAND_DISPLAY - similarly, this is needed for wayland-native services
|
||
|
# - I3SOCK/SWAYSOCK - allow services to talk with sway using i3 IPC protocol
|
||
|
#
|
||
|
# 2. `xdg-desktop-portal` requires XDG_CURRENT_DESKTOP to be set in order to
|
||
|
# select the right implementation for screenshot and screencast portals.
|
||
|
# With all the numerous ways to start sway, it's not possible to rely on the
|
||
|
# right value of the XDG_CURRENT_DESKTOP variable within the login session,
|
||
|
# therefore the script will ensure that it is always set to `sway`.
|
||
|
#
|
||
|
# 3. GUI applications started as a systemd service (or via xdg-autostart-generator)
|
||
|
# may rely on the XDG_SESSION_TYPE variable to select the backend.
|
||
|
# Ensure that it is always set to `wayland`.
|
||
|
#
|
||
|
# 4. The common way to autostart a systemd service along with the desktop
|
||
|
# environment is to add it to a `graphical-session.target`. However, systemd
|
||
|
# forbids starting the graphical session target directly and encourages use
|
||
|
# of an environment-specific target units. Therefore, the integration
|
||
|
# package here provides and uses `sway-session.target` which would bind to
|
||
|
# the `graphical-session.target`.
|
||
|
#
|
||
|
# 5. Stop the target and unset the variables when the compositor exits.
|
||
|
#
|
||
|
exec $exedir/session.sh
|