Git survey

The git developers are doing a git survey again, follow this link to take it.

Compiz and Fedora

There was a big discussion about enabling compiz by default in Fedora on fedora-devel list a couple of days ago. Reading through the thread I realized that we never really communicated our plans here very well. I sent out the writeup below to explain a bit where we're going with Fedora and what the road blocks are, but I figured it wouldn't harm to also blog it.

We are working towards being able to enable a compositor by default.

Redirected direct rendering, Xv, Java problems, these are problems in the drivers and X server and affects all compositors. To get this done, we need to land a big chunk of code in the kernel (the DRM memory manager), we need to update the X server, the 2D drivers and the 3D drivers to take advantage of the new memory manager. We need to fix Xv. Hopefully the OpenGL support will broaden to support more chipsets (nouveau, avivo). Getting all this to a shippable state may take years, and in the mean time, the composited desktop, whether it's compiz, kwin4 or something else will only be an opt-in tech demo.

Once we get there, the default compositor will be compiz.

Some people can't get over on the wobbly windows and spinning cube, and claim it's over the top or apparently get nauseous. At the core, compiz is just a very efficient OpenGL redraw loop with a flexible plugin architecture. Compiz allows burning windows and spinning cubes, but we ship it in a very toned down default configuration that looks a lot like good old metacity. Consider xeyes; like wobbly windows, it's a neat tech demo and shows off the flexibility of X, but just because nobody runs xeyes for more that 2 minutes at a time that doesn't mean that X (or shaped windows) isn't useful.

A valid point about compiz is that it is not yet a great window manager. Metacity has a few years of head start there, but that doesn't mean that we can't fix compiz or that it'll be duplicated effort. For now, our (Red Hat) efforts have gone towards fixing the big underlying shortcomings in the X and OpenGL stack, which has left compiz in Fedora with a set of minor (but certainly annoying) windows manager bugs. Other spins (Fedora KDE or Fedora XFCE) can set up different default compositing managers, and they will of course benefit from the infrastructure work mentioned above.

We're not working on making metacity a compositing manager.

We tried it and decided that the metacity code base was not a welcoming place for a compositor. When we put down the work in metacity, the conclusion was to leave this very stable and well tested code base alone instead of injecting an OpenGL based compositor. The flip side of this decision is that we can now do a clean break in compiz and assume throughout the code that we're an OpenGL based combined compositing and window manager.

Compiz fusion and configuration tools.

desktop-effects is close to what we want to ship by default, perhaps we want to fold it into the new gnome-appearance-properties capplet as a new tab. The default compiz configuration and the set of options we expose outside gconf-editor is intended to be very conservative. At the same time, we want to allow installation of other compiz configuration managers and the compiz fusion plugins for people who like the tweak-ui kind-of tools.

Power consumption and other hand-wavey fud arguments.

Clearly running a 3D screen saver at the full frame rate is going to burn more battery than the blank screen saver, but that's not really relevant here. When idling, compiz and metacity use exactly the same amount of power. There are no code paths anywhere in the stack that "turn on 3d powerplanes". My bet is that it's more power consuming to wake up all applications to redraw their exposed areas under the window you're dragging than it is for compiz to just recomposite that out of textures already in video memory.

Redirected direct rendering

Also known as AWESOME. Normally, when an application renders to an X window, the contents appear in the framebuffer immediately. The COMPOSITE extensions lets an application, typically the compositing manager, redirect that rendering to an offscreen pixmap. The compositing manager is then responsible for compositing the window contents into the framebuffer, for example by mapping it onto a cube or a wobbly window. All regular X rendering respect this redirection, since the rendering requests go to the X server, which can then target it to whichever pixmap it wants.

However, the default rendering mode for accelerated OpenGL, direct rendering, is a little different. With direct rendering, the application goes through an initial setup sequence with the X server, to acquire the address of the framebuffer and the shared back and depth buffers. After this step, the application renders by programming the GPU directly to render into those buffers. This, of course, is a feature - direct rendering acheives a siginificant performance boost over having to send every request to the X server. However, the direct rendering application isn't aware that a window might have been redirected and renders to the framebuffer regardless. This is typically not what you want:

DO NOT WANT

To me, this is one of the biggest problems in our rendering stack. I'm convinced that the composited desktop has to be a standard feature of the future Linux desktop: Whether or not you want spinning cubes and wobbly windows, there is no denying the benefits of flickerless redraws and ARGB visuals. Unfortunately, with a bug like this, we can't really enable it by default. Especially when interest in OpenGL backed toolkits (clutter and pigment) is starting to pick up.

What you want, is to let the OpenGL driver know when a window is redirected and make it target its rendering to the offscreen pixmap. Conceptually, it's easy enough and we've known how to do it for a while, but there's a lot of details to get right. One of the big pieces of the puzzle fell in place with Tungstens Graphics' DRM memory manager (TTM). Dave Airlie and I added TTM support to EXA and the intel DDX driver, and from there I was able to make the DRI driver render into the TTM buffers allocated by EXA. And given that the Pixmaps for the redirected windows are now backed by TTM buffer objects, we can add a zero-copy texture from pixmap implementation to the mix:

DELICIOUS

If you want to try it out, I have the code in the exa-ttm branch in my personal drm, xserver, mesa and xf86-video-intel repositories on freedesktop.org. It's not at all easy to set up and the current implementation is only a prototype. It will be a while before this stuff can get upstream; we need to discuss how we want the interfaces between DRI/DDX/DRM/EXA to look etc, but hopefully we can figure that out at XDS.