This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex

Should we fork Mutter?

A wayland compositor is in many ways different than a traditional X WM/compositor, so it was proposed to fork the existing code base into a new project, jokingly named "muttland", where we would be free to make the necessary refactorings and to evolve the internals independently of the original mutter. The alternative is one code base, with runtime selection through a command line flag.

This page tries to describe the pros and cons of either approach.

In favor of muttland

General pros

Subsystems that we would rewrite for muttland

Note: input events in XWayland are delivered to the X window associated with the wayland surface that received the event, irrespective of what DIX believes to be below the pointer, but the event coordinates are obtained by summing the relative coordinates from the event with the absolute location of the window according to X, so we still need to configure X windows. Probably, we also need to keep a consistent stacking view and mapped state in the server, to account for XQueryPointer.

Note: in any case XWayland does not see other wayland clients, so X features that allow interaction with other clients (such as XQueryPointer, _NET_WM_ACTIVE_WINDOW, XGrabPointer, setxkbmap, etc.) would regress, even if we keep all the existing X paths.

Owen: In terms of things like stacking, XQueryPointer, etc, the expectation is that the view that an X app sees is that Wayland apps just aren't there. The number of things that will break should be quite small - eye dropper color pickers, perhaps. But we strongly need applications to be internally consistent - if an app puts up a OR window at a particular position in its window, it should be able to XQueryPointer and see it there, and it should be stacked over the window in X terms if and only if the user sees it that way. Less strongly, it would be nice to keep this type of interactions between X apps working - so that funky multi-process X apps work right. That's not a priority, but it probably falls out for free.

In favor of mutter --nested

General pros

New features that would be duplicated in muttland


2024-10-23 11:17