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?
Yes, Wayland is a stable base protocol with a mechanism for negotiating versioned “extension protocols” at runtime.
+1 to globally auto-connect since the snap is meant to provide wayland to any wayland-aware client and the protocol is stable.
@reviewers - can others please vote on this?
@niemeyer - since this is a global auto-connect of a content interface, it would be nice to get your vote as well.
+1 from me too, rationale from Jamie makes sense and the developer’s explanation and intent are also consistent with auto-connection use.
@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:
How does that sound?
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.
@alan_g - can you comment on Auto-connect for wayland-socket-dir content interface and let me know what snaps you want connected?
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.
For future reference: we’ve moved away from this approach and are using the wayland interface itself going forward.