I took another look at this and am no longer seeing an issue with the wayland client socket if the wayland socket is a symlink from /run/user/<uid>/snap.foo/wayland-0 to /run/user/<uid>/wayland-0 or if /run/user/<uid>/wayland-0 is bind mounted into /run/user/<uid>/snap.foo/wayland-0. I have seen that 16.04 and 17.04 got refreshes of the GNOME stack so perhaps there were bug fixes which is why I’m no longer seeing the issues from before.
For the moment, I am going to create a very simple wayland interface that simply allows access to /run/user/<uid>/wayland-[0-9]*. I’ll also send up something so desktop-launch can set the necessary variables (though, the desktop team might want to do something different). I have tested this with:
- an updated gnome-sudoko with gnome-3-24 platform snap that uses a symlink from
$XDG_RUNTIME_DIR/wayland-0to$XDG_RUNTIME_DIR/../wayland-0on 17.10 - an updated gnome-sudoko with gnome-3-24 platform snap that uses a symlink from
$XDG_RUNTIME_DIR/wayland-0to$XDG_RUNTIME_DIR/../wayland-0on 17.04 - an updated gnome-logs-udt snap that uses a symlink from
$XDG_RUNTIME_DIR/wayland-0to$XDG_RUNTIME_DIR/../wayland-0on 16.04
In all cases, if the wayland socket was detected, I’d set:
export WAYLAND_DEBUG=1
export GDK_BACKEND="wayland"
export CLUTTER_BACKEND="wayland"
to force the use of wayland and would observe that wayland was used with no wayland server or client socket denials.
@jamesh, for now, I am going to pursue this simple interface to unblock people from playing with wayland since the interface accesses will be compatible with anything we do in the future with this interface. In the future I think we may want to consider moving wayland, dconf, pulseaudio and /run/user/<uid>/bus (the session bus) into a per-user mount namespace on top of the snap namespace like you are looking at for the portals work since that is similar to what upstream portals, wayland and dconf have been designed for. By doing that I suspect we’ll have fewer issues and can more closely follow upstream changes.