Compiz in a strange new land

Mark Shuttleworth recently proposed an idea that a lot of people have been pondering for a while. The idea is simple: the linux desktop needs a new windowing system. While I don’t have enough expertise to make a fair judgement as to whether it’s time to move away from X11 and to something like wayland , I certainly think the idea is interesting. Why not? We have nothing to lose by at least sticking our toes in the water so to speak, and I certainly wouldn’t mind a challenge. So yesterday I took the plunge and compiled wayland for myself, just to try it out.

That there is a screenshot of Wayland running in X11 mode (where it just runs as a normal X11 client rendering straight into an EGL buffer on the screen).  I also got it to run in “drm” mode, which is basically where you run it in a VT and it will render the entire screen, much like X11 does.  Note that for both the X11 approach and the drm approach you still need an OpenGL ES (EGL) capable driver which supports libdrm and kms. Also, I believe that it still requires pageflipping support – and I think this is still only supported upstream in the intel drm (there are patches to make it work on nouveau and radeon, but I did not try them) out myself.

This leads us to the inevitable question: where does this leave compiz? As you probably know, Compiz is a window manager for X11, which basically means that it needs X11 to, well, work. However I’m confident that one day this wont be the case. In the same way that we split the opengl and composite plugins out of core so that we could have different rendering models, I am confident that with a bit lot of typing we can do the same with the remaining X11 bits in core – and split them out into an X11 plugin. This would mean that all current plugins would depend on the X11 plugin and then we could work out a small layer of abstraction so that basic WM functions could be exposed on both an X11 plugin and a Wayland plugin.

The other interesting thing about wayland is its display model. Unlike X11 where we have a bunch of clients push to a display server, and then an external window manager / compositing manager process, in wayland we have a single process for a display server and compositing manager. There is no window manager, all of that is pushed to the clients (move, resize, etc). But this doesn’t matter any more, since all that matters is that we’re in charge of compositing them which means that we have full access to their buffers and the stacking of those buffers (plus, you can still place a buffer wherever you want on screen, it is just up to the client to move itself).

The other interesting thing about wayland is that it takes an “everything is a compositor model“, which basically means that we can create our own buffers using libwayland and then composite each individual app into their own buffer and manage all the little widgets and everything ourselves. And then for example, firefox would become a compositor too, and would be able to manage all of it’s own tabs, widgets etc all exposed as GEM buffers.

Of course, I don’t see compiz ending up on wayland until someplace in the far future, but it’s good to start thinking about these things now and see how they fly. I understand that there is quite a lot of debate over whether it is feasible to be thinking about X Server replacements at this point in the game, especially since it has been done before with not too much success. But I believe this time wayland will be different to those cases. So we should at least try it.

Update: Considering that there aren’t any videos of it around, I also decided to include a video of how the libdrm version of wayland works.

Second Update: Some sites have been wondering if I’m proposing that we drop the X11 backend and rewrite for wayland. This really isn’t the case. I’ve been planning to have an X11 backend for a while now anyway, since I thought it would be cool if we could port to things like Haiku. Since the move to wayland isn’t going to happen for a few more years / potentially at all, I don’t expect that this X11 backend is going to receive little love. In fact I think quite the opposite will happen. The whole point of this blog post was not to announce anything – it was to say how a Wayland based compiz could work, not that we will be “rewriting for wayland”. I mean, the entire development team just spent a year and a half rewriting the core in C++ (plus using all the 0.9 APIs), I don’t think I want to go into “hibernation mode” just yet and rewrite again for wayland 🙂

Third Update: Just talked to Kristian Hoegsberg about some possible compiz implementation details. Apparently wayland also gives you full access to the input as well, which of course means we have input redirection for free 🙂


23 thoughts on “Compiz in a strange new land

  1. So client-side window decorations? Oy vey.
    And where do window managers (and WM functionality) stand in general; what is the ‘upgrade’ path for users of a *box, dwm, awesome, etc? Would such projects be doomed, were X11 to fall out of favour? Are such projects limited by the hints [un]supported by Wayland?

    1. All window managers become compositing managers, and because we can redirect windows into our own buffers (since we control the entire compositing process) we can enforce our own window decorations.

      *box dwm, awesome etc would just composite buffers however they like on screen. So you can still do tiling etc. Except that they’d be libwayland servers (so *box, dwm, awesome etc would be your display server)

  2. Is NOMAD still alive? I’ve not checked recent releases of openSUSE.
    Will it not be needed for compiz-like WM when Wayland matured?

  3. Isn’t Wayland just a Xorg+CompositingWM in a single application? Meaning, isn’t compiz have to be a part of wayland to work under it?

  4. Gracias por toda la información que proporcionan, a pesar de que tuve que traducir el artículo me resulto bastante útil y pienso seguir visitándolos^^

  5. Hi, I believe your site could be having internet browser compatibility issues.
    When I look at your blog in Safari, it looks fine however,
    when opening in Internet Explorer, it’s got some overlapping issues. I simply wanted to provide you with a quick heads up! Besides that, great site!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s