The Canonical Mir team has created the mir-kiosk snap which provides support for “client” snaps using Wayland. The wayland-socket-dir content interface is needed to support the Wayland protocol.
As this is the primary support for IoT graphical snaps we would like a snap declaration to auto-connect this interface.
default-provider: mir-kiosk:wayland-socket-dir
We currently are working to populating the store with some examples and expect others to be developed.
Are the protocols used over these sockets considered stable? I’m wondering because currently you use a versioned ‘mir-libs-1604’ but an unversioned ‘wayland-socket-dir’. Is it worthwhile to do ‘wayland-socket-dir-1604’ instead?
@jdstrand How does that fit in the context of the sprint session we had last week to discuss precisely the case of the wayland socket?
The label for the content could probably be improved as well, but let’s please discuss the details around the wayland socket itself, since we have that fresh in our minds still.
My understanding (and @Saviq can correct me) is that this is still needed so the sockets are exposed to the clients on Ubuntu Core in an expected location by the clients. The main bit last week was that the server (slot side) was having trouble with where it put the sockets, but the symlink approach we discussed will fix that.
Understood. So given the agreements from the sprint, I suggest:
Naming the interface as “wayland-socket”, on the basis that all content interfaces are “dir”
Restricting the auto-connection to known snaps only for now until we understand a bit better how we want to evolve this interface properly. For casual readers, please note that the connecting to the usual Wayland socket on a classic desktop does not need this interface.
The thing is we might only need one socket after all - the main $XDG_RUNTIME_DIR/wayland-$WAYLAND_DISPLAY one. The other sockets all seem to be accessed via a file descriptor being passed on that original socket. We’re confirming that is the case and will report back.
Based on @niemeyer’s feedback, I’m prepared to grant any snap declarations for this. The request was for global auto-connect and @Saviq mentioned maybe something else could limit the number of sockets.
Maybe I don’t understand what you need. we want any graphical snaps to be able to auto-connect, I can’t provide a complete list of these.
As things stand now this is any that request default-provider: mir-kiosk:wayland-socket-dir, but the exact way to identify these might vary with the discussions above about name and “one socket”. We’re working to resolve these discussions.
The only one I have in the store is mir-kiosk-apps, I think @greyback and @ogra have been working on some more. We’ve also got some examples in the tutorials that would benefit from autoconnect.
I think what @niemeyer was asking for is that we rollout the auto-connection slowly and deliberately at first before granting it to everything. As such, can you enumerate the snaps that you are responsible for that need it today. Then new snaps we can evaluate as we go.
I’d like to better understand if mir-kiosk:wayland-socket-dir is actually even needed any more. I spoke with @greyback via email and I suspect that the content interface can go away, but need to hear back.
As @jdstrand mentioned, I’m working on removing the need for this interface entirely, so we can just use the wayland interface. I’ll post an update once I’ve got it sorted.
-G
@jdstrand@niemeyer so long as auto-connect is not global it is not useful to enable for the example client snaps we own (as anyone trying to copy these will need to connect manually).
If/when there are snaps that do require auto-connect we can request it for them.