It was previously agreed to that snappy should set XDG_RUNTIME_DIR to /run/user/`id -u`/snap.$SNAP_NAME and create the directory. Today, snappy sets XDG_RUNTIME_DIR but does not yet create the directory (the directory seems to be created by gtk3 apps at least).
Wayland puts its socket into XDG_RUNTIME_DIR, but the server uses XDG_RUNTIME_DIR=/run/user/`id -u` so the socket is in /run/user/`id -u`/wayland-0. Clients start and are unable to connect because /run/user/`id -u`/snap.$SNAP_NAME/wayland-0 doesn’t exist and they fallback to mir and X.
In retrospect, upstream GNOME feels that the current situation is not correct and that snapd should “use mount namespaces to set up a clean copy of the xdg_runtime_dir at the same path, with the subdir bindmounted through”. Eg:
- create /run/user/`id -u` as a clean new tmpfs inside the snap and create a snap specific subdirectory (ie, snap.$SNAP_NAME)
- share /run/user/`id -u`/snap.$SNAP_NAME, such that it is at the same location inside and outside the snap
- bind mount /run/user/`id -u`/wayland-0 from the outside into the snap
This is possible, but means we have to allocate RAM for each tmp area and it means that the launcher needs to find wayland-0, which adds some complexity when it doesn’t exist yet, when WAYLAND_DISPLAY is set to something other than ‘wayland-0’ or if there is more than one ‘wayland-N’ in the dir. Upstream gtk hackfest discussed the possibility of wayland adding per-client sockets, which is something that is being looked at with dbus.
While the details are being worked out, the gtk3 desktop part will do something along these lines:
cd $XDG_RUNTIME_DIR && test -S $XDG_RUNTIME_DIR/…/wayland-0 && ln -s $XDG_RUNTIME_DIR/…/wayland-0 .