The mir-kiosk snap is a confined Wayland server and used to work on both Core and Classic systems. However, towards the end of last year changes were made to the snap support on Classic that prevent it working.
You might wonder “why run mir-kiosk on Classic?” but, empirically, about half the installs are on Classic systems (not all of them Ubuntu). These only work on Classic systems because there is a “work-around”: installing the mir-kiosk snap with
--devmode but that is hardly satisfactory.
The first symptom is that Wayland compositors need to offer an endpoint in
$XDG_RUNTIME_DIR- and on Classic that directory does not exists, cannot be created in the snap and, if created “by an outside force” cannot be used. Running with
--devmodesuppresses this symptom.
If that were solved, then consumers of the Wayland interface need to be able to find that endpoint (or a link that behaves like it) in their own
$XDG_RUNTIME_DIR. The way things are currently working on Core (and used to work on Classic) isn’t “obviously correct” either: both server and client snaps mess with
$XDG_RUNTIME_DIRso that the endpoint can be shared.
Clearly, there are now differences in the way the
wayland interface works between Core and Classic systems but it is not clear:
- how to implement a confined Wayland server snap that can work on Classic; and,
- whether there is an approach that works on both Core and Classic.
Is there an approach, or plan, that allows confined servers on Classic to create a Wayland that can be accessed by confined clients?
Or is the
wayland interface not intended to be usable for this scenario? Much of the discussion I see (e.g. The desktop interfaces) appears to assume that it is for accessing a Wayland compositor provided by the system.