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

  • Cleaner code base in both projects
  • No risk of regressions in mutter

Subsystems that we would rewrite for muttland

  • Input event handling, through clutter and removing the manual XInput2 code. We can't use the existing X code through XWayland because active or passive grabs have no effect.
  • Focused window tracking (Pwen: You can't remove any of the current complexity - we still need to track the X focus correctly - X apps rely on the server's notion of focus and the events the X server sends, and we need to be in sync with that)
  • The XKB bell code (Owen: this is still needed - someone needs to play the correct sound for X bells - I don't think there is any change to this code)
  • Mouse cursors

  • All the X11 composition parts (TextureFromPixmap, Damage events) are dead code for a wayland compositor

  • Display configuration (we would remove the XRandR/Xinerama path)
  • Input barriers
  • Part of MetaUI would be rewritten in clutter, if we want to apply it to wayland windows (Owen: a lot of this could be done completely without reference to Wayland/X - would fix things like the Alt-Escape outline)
  • Keybindings
  • Lots of crazy EWMH features we support like external pagers and struts
  • Session management (goodbye XSMP/libICE)
  • Maybe, we could accept the minor feature loss, and remove the new synchronized drawing for X clients (the only toolkit using it is Gtk 3, and that has a wayland backend) (Owen - if we drop that support, it hurts any attempt to get toolkits like Qt to support the feature. That matters, since people will be using GNOME 3.8, 3.10 with X for long after GNOME moves on to Wayland. Would take some detailed study of how Xwayland works to figure out if it can be made to *meaningfully* work with correct integration of damage and redraws.)
  • Window constraints would need to be revisited, to account that in wayland the window size is completely determined by the client (so care is needed to avoid loops of configure events)
  • At a higher level, we could revisit the split between compositor, core, ui and wayland and possibly remove the X based accessors from UI to core

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

  • One code base to maintain instead of two
  • New code is tested by X users too
  • Saves having to build two GNOME Shells (or do weird linking tricks)
  • Don't have to implement the DBus stubs for something like display configuration twice, just the code behind the stubs

New features that would be duplicated in muttland

  • HiDPI
  • "Presentation" screens (do we need to backport that to mutter?)

Initiatives/Wayland/GnomeShell/ForkingMutter (last edited 2013-11-22 20:55:30 by WilliamJonMcCann)