sway: add wrapper scripts

[gspe]

@olafmersmann I'd like to ask you what do you think about adding some wrapper scripts to help user with the problem of setting enviromental variable correctly in sway and wayland in general. I'm thinking about this: https://man.sr.ht/%7Ekennylevinsen/greetd/#how-to-set-xdg_session_typewayland https://en.opensuse.org/Portal:OpenSUSEway/Configuration

Based on OpenSuse configuration I'm thinking about having:

• a file to store enviromental variables /etc/sway/env :

  
  # recomended enviroment variables for sway based desktop
  MOZ_ENABLE_WAYLAND=1
  QT_QPA_PLATFORM=wayland-egl
  CLUTTER_BACKEND=wayland
  ECORE_EVAS_ENGINE=wayland-egl
  ELM_ENGINE=wayland_egl
  SDL_VIDEODRIVER=wayland
  _JAVA_AWT_WM_NONREPARENTING=1
  NO_AT_BRIDGE=1

QT theme

QT_QPA_PLATFORMTHEME=qt5ct

- a wrap script to run sway `/usr/bin/sway-run.sh` :

!/bin/sh

Session

export XDG_SESSION_TYPE=wayland export XDG_SESSION_DESKTOP=sway export XDG_CURRENT_DESKTOP=sway

this file imports sway desktop enviroments

set -a . /etc/sway/env set +a

exec sway $@

- a desktop file to run sway from login manager `/usr/share/wayland-sessions/sway.desktop` :

[Desktop Entry] Name=Sway Comment=An i3-compatible Wayland compositor Exec=sway-run.sh Type=Application

edit: add missing `exec`

[ericonr]

I'm very against this. That's waaaay too much vendoring of things that, for the most part, are a user preference. And making a special case for sway vs the other wayland compositors doesn't make sense. Upstream should ship saner defaults and/or improve their configuration file to allow setting the environment.

SDL_VIDEODRIVER=wayland was also quite crashy for me, iirc.

Should use exec sway $@, btw, otherwise signal handling gets all messed up.

[gspe]

Just an observation, these environmental variables just set app to use wayland as preferred video server and nothing else.

Proposed /etc/sway/env file is not sway specific and can be moved somewhere else and used by other wayland compositor, mine was just an example for the actually most know wayland compositor.

[ericonr]

We could consider shipping a wayland friendly setup for greetd, maybe, but besides that I'm not really sure about this.

[olafmersmann]

We could consider shipping a wayland friendly setup for greetd, maybe, but besides that I'm not really sure about this.

Maybe add a INSTALL.msg file that lists the environment variables for new users? Or maybe we could add it to the Wayland section of the handbook?

[gspe]

Or maybe we could add it to the Wayland section of the handbook?

This could be a solution, at least user with doubt about how to setup wayland wm can find a solution quicker.

[kkga]

I generally agree that this is better left for the user to decide how to setup their Wayland session, so either a post-install message or some specific details in the handbook would be good.

We could consider shipping a wayland friendly setup for greetd

:+1: This would be nice! I wanted to try out greetd for a while.

[travankor]

@kkga I have a pending package for greetd #20873. It got delayed for reasons... but it's ready for review now.

Please give it a shot and report issues/suggestions.

[gspe]

I'll post an update here so if someone have problems with D-Bus configuration can find some help. I've taken inspiration from how kde plasma wayland is started, https://github.com/KDE/plasma-workspace/blob/master/startkde/plasma-dbus-run-session-if-needed

I have modified the wrap script to run sway /usr/bin/sway-run.sh as follow:

#!/bin/sh

# Session
export XDG_SESSION_TYPE=wayland
export XDG_SESSION_DESKTOP=sway
export XDG_CURRENT_DESKTOP=sway

# D-Bus
# If the session bus is not available it is spawned and wrapper round our program
# Otherwise we spawn our program directly
drs=
if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]
then
   drs=dbus-run-session
fi

# Environment
# Source environmental variable from all files in PATH_ENVIRONMENT
# file should be named *.conf and have KEY=value format use # for comment
PATH_ENVIRONMENT=$HOME/.config/environment.d
if [ -d "$PATH_ENVIRONMENT" ]; then
  for i in "$PATH_ENVIRONMENT"/*.conf ; do
  if [ -f "$i" ]; then
    set -a; . "$i"; set +a
  fi
  done
fi

exec ${drs} sway "$@"

So if there is already a running dbus user session sway is started normally but if there isn't any the script start one dbus user session and sway inside it.

With this script Environmental variable are read from ~/.config/environment.d directory, like how systemd user does. User can put any file ending in *.conf inside this directory and they are sourced before sway start importing any KEY=value defined into environment. In my case i have ~/.config/environment.d/wayland.conf like this:

# recomended enviroment variables for sway based desktop
MOZ_ENABLE_WAYLAND=1
QT_QPA_PLATFORM=wayland-egl
CLUTTER_BACKEND=wayland
ECORE_EVAS_ENGINE=wayland-egl
ELM_ENGINE=wayland_egl
SDL_VIDEODRIVER=wayland
_JAVA_AWT_WM_NONREPARENTING=1
NO_AT_BRIDGE=1

# QT theme
QT_QPA_PLATFORMTHEME=qt5ct

With this modification I don't have /etc/sway/env anymore but an user defined configuration ~/.config/environment.d/wayland.conf

[ericonr]

At issue here is that Void can't ship wrapper scripts for every WM we have (there are many). Some display managers support a setup script which can set these variables for you and/or go through ~/.config/environment.d, and I would recommend using those.

The root cause is that, as a distro that doesn't use systemd, we lose out on some of their goodies, which include seamless dbus user session. If you have suggestions for improving the docs about dbus, feel free to open an issue there. However, I don't know how we should proceed beyond that, since, for better or for worse, void supports dbus-less systems.