Introducing Musa, a multiseat Wayland compositor

Although Wayland has had native support for multiple seats since its introduction, the state of multiseat support in both servers and clients is currently lacking. Some compositors like Sway have some support for multiseat in their codebases, but the multiseat experience as a whole is often not very usable and feels bolted on. This is what prompted me to start creating Musa.

Features

• Configuration over specialized Wayland protocols
  • You are not limited to a single configuration format, and configuration GUIs are not out of the question either!
• Full multiseat usability
  • You can resize windows from multiple edges simultaneously with multiple cursors and touchpoints
  • ext-transient-seat-v1 implementation for virtual seat creation (supported by wayvnc)
    • So everyone connecting to your VNC server can get their own seat!
• A custom window management protocol for tiling window managers
  • Including a dynamic tiling one written in GNU Guile

Configuration

All compositors require configuration, and the selected configuration language greatly affects what kinds of configurations one can effectively write. The Wayland compositor river solves this by not having a configuration language at all: all configuration is done through a Wayland protocol that can be either used through its included configuration tool, riverctl, or through any programming languge with a Wayland client implementation or libwayland binding available.

Musa takes inspiration from river in its configuration system while taking many things further: all configuration is done through specialized protocols instead of a single text-based one. This approach increases the amount of required code, but it makes the system more reusable: the configuration protocols can send events to clients in addition to handling their requests, which allows writing flexible configuration UIs for Musa. As Musa is still early in development, such UIs haven’t been implemented yet, but allowing ones to exist is an explicit design goal.

Window management

One of the best features of X11, the predecessor of Wayland, was how it allowed one to write their own window managers without having to touch windowing server code. The interface was neither pretty nor easy to use, but compared to writing an own windowing server, it was the better alternative. Wayland got rid of this capability to keep the protocol simpler and to allow layout updates to be atomic, but this left many small window managers behind. Now everybody had to write their own compositor, and although wlroots makes this reasonably simple, most window manager authors have neither time nor energy for it.

A full X11-style interface would not make sense over Wayland because there is no way to make it atomic and race-free, and being atomic is the whole point behind Wayland¹. This is why Musa’s window manager interface takes a different approach. Although many details of the current design will need to be changed in the future, the core principle is clear: the compositor gives the window manager all the basic information it needs for its operation and lets it commit window rectangles atomically. Limiting the available functionality allows one to make the implementation atomic: if, for example, a window gets destroyed, the compositor will freeze all the other ones on the layout until the window manager has committed new window dimensions and the windows have fully resized.

Although Musa’s window management interface is simple, it is relatively powerful: you are free to implement your own tag systems, window rules and layout algorithms in any programming language from which you can use Wayland.

Musawm

Musa is implemented in Zig, which is a very nice programming language, but no language can be a good fit for everything. For writing less performance-sensitive software like a window manager, a higher-level language is a better choice as it allows more rapid development with a better development experience. Hence, Musa’s included window manager, musawm, is implemented in GNU Guile, an implementation of the Scheme programming language with a simple foreign function interface and great REPL support.

Musawm is designed as a set of modules that can be loaded by the user from their window manager configuration. This means that it is configured in Guile directly, allowing high customizability. As musawm supports Guile’s REPL server, you don’t need to restart musawm to apply your configuration changes: you can just use Geiser and work directly inside a running window manager while making your changes.

Approaching daily usability

Musa is still early in development, but it is already starting to look somewhat usable. For daily usability, the component requiring the most work is musawm. In its current state, musawm is a simple dynamic tiling window manager with little configurability and bad focus semantics, but it has lots of potential to become better in the future.

Everything in Musa is still very unstable and in a constant flux, and in case you decide to try it out anyway, please report any issues you find to the issue tracker. If you have any ideas or concerns, feel free to discuss them at my public inbox. Patches are definitely appreciated too!