Allow embedding foreign wl_surfaces

Hey there 👋,

one of the devs of smithay here. I recently got involved in development for Pop!_OS, which is likely to move away from GNOME at some point. In pursue of developing our own desktop environment, we found a use-case, which we believe is not covered by currently available wayland protocols. I am reaching out to gather some feedback and see, if there is interest in our proposal.

We would like to have extensible panel- and dock-clients, but would prefer to run "applets" in a separate process. While there are a ton of possible technical solutions, we would like to use a mechanism similar to what XEmbed offered on X11 for a bunch of reasons:

• We do not need to know, what exactly the client is drawing, we just want to display it inside our panel or dock.
• There is already a software running to composite different clients: the wayland compositor. We could of course implement an embedded compositor (like the wayland docs suggest, but that increases the complexity quite a bit).
• Clients managing surfaces on their own (opposed to the dock doing that) could use almost any ui-toolkit they please out-of-the-box, instead of the panel/dock having to pass on input events and what not.

xdg-foreign already seems to be half the way there, but it is currently limited to toplevel surfaces and offers the exporter no way to precisely position the imported children.

Already lifting the first of these constraints would make xdg-foreign a lot more useful for our use-case. Then we could create a subsurface for the dedicated space of a new applet, export that, pass on the handle and the compositor would position the applet inside that subsurface.

For the compositor this would mean being able to attach toplevels into arbitrary places in existing surface trees, which is obviously not matching with the existing semantics of xdg-foreign:

Calling this function sets up a surface to surface relation with the same stacking and positioning semantics as xdg_toplevel.set_parent

The second problem is, that malicious clients could be submitting buffers larger than the area they are supposed to sit in. This could for example be solved by expressing those size constraints via the protocol and making this kind of behavior a protocol error.

To sum up my questions:

• Is this possibly a use case, that could be handled by an extension of the xdg-foreign protocol?
• Is this a use case, that should rather be handled by a different protocol, that allows sharing wl_surface between processes or at least enables more complex parent-child-relations across processes?
• Is there interest in adopting any of this into wayland-protocols?

We would like to build a solution, that works with different desktop environments today, which is why I am suggesting extending xdg-foreign, given its already widespread adoption and similar - although much narrower - purpose. But if there is interest in developing a new protocol together, I am also happy to put the work in.

Thanks for you time! 🙂