Wayland: there have been many blog posts, articles, and news items about the new Linux display protocol. There have been developers working to extend the protocol for new and extremely helpful use cases, but new frontiers continue to be explored: putting a multiseat Wayland compositor into a toolkit widget.
Due to Wayland’s philosophy of “build your own compositor,” there is no de-facto implementation of a Wayland display server that is analogous to Xorg for X11. Wayland implementations are written using the libwayland server API, and this is flexible enough to be used even in the case of a widget. Overall, the only noteworthy difference between putting a compositor in a widget and a normal nested compositor is that the output size is set to the size of the widget instead of the size of the window. With this in mind, a compositor widget can be manipulated just like any other widget, as it manages all protocol-related matters internally.
[iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/xZGYdg21IS0″ frameborder=”0″ allowfullscreen]
weston-terminal running in a widget in an X11 window.
Implementing Clipboard Sharing and Drag-N-Drop
This project had a number of difficulties along the way, most of them being related to clipboard and drag-n-drop support. A nested compositor of this type is significantly less useful if it lacks support for these things, and so it was necessary to add bridging for Wayland<->Wayland selection transfers as well as X11<->Wayland transfers. Clipboard selections were the easier part to handle in this case, as they do not require mouse/touch interactions and have no positioning data. For Wayland<->Wayland requests, all that’s needed is to transparently proxy all the data offer protocol exchanges to and from the parent compositor, and then pass any resulting file descriptors to the clients. Under X11, however, data must be manually read from or written to X11 window atoms and the selection requests need to be translated into Wayland equivalents.
[iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/o0a0I4Ao9Ng” frameborder=”0″ allowfullscreen]
Clipboard bridging under X11
Drag-N-Drop (DND) support was considerably more difficult. Not only does positioning affect the operation, but when the drag leaves the widget it becomes necessary to proxy the drag surface into a new window and initiate a global DND operation instead of working only within the widget. This leads to a new set of issues where buffer management for the drag surface must be adjusted to account for different render timings of the global drag window, which reuses the same buffer. The behavior is different between X11 and Wayland as well. Under X11, when dragging back to the originating widget, the global drag can be canceled. However, under Wayland the operation remains global and the result will be that the widget proxies a selection send through the outer compositor back to itself.
[iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/muTkLt1VNlw” frameborder=”0″ allowfullscreen]
DND bridging under X11
Adding full support for bridged DND also means that dragging between separate compositor instances also becomes possible.
[iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/lonwtDsz9VE” frameborder=”0″ allowfullscreen]
DND bridging between compositors under X11.
Another challenge with the process of putting Wayland into a canvas widget was supporting subsurfaces and other types of child surfaces. In Enlightenment, these are handled as regular objects which are stacked above the parent, but this makes the object tree more difficult to debug. The compositor widget does things a bit differently by making child surfaces into child objects of the parent surface, creating an object hierarchy which is much easier to read and debug.
[iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/u8bbTAVJirQ” frameborder=”0″ allowfullscreen]
Subsurfaces under X11.
Using the Compositor Widget to Sandbox Applications
The compositor widget has a number of useful features, but perhaps the most overlooked feature would be the ability to run applications in a sandbox. Any application launched inside has no ability to directly affect anything outside of the widget, meaning that questionable applications can be run in a safe environment from the display server’s perspective. While it has obvious uses in security, the more mundane usage could simply be embedding a web browser into an application without the need to connect to any browser engine’s embedding API.
Adding a compositor widget to an application can allow content to be embedded in isolation. It provides seamless integration with existing desktop interactions and requires no special handling to be placed into a UI layout. It also allows Wayland applications to run under X11, although this is perhaps not as useful since there are very few Wayland-only applications at present.