506	-    int width = outputs.front ()->width ();
507	-    int height = outputs.front ()->height ();
508	-    bool sizeDiff = false;
509	-
510	-    /* "One big wall" does not make sense where outputs are different
511	-     * sizes, so force multiple walls in this case
512	-     *
513	-     * TODO: Is it possible to re-create "one big wall" using
514	-     * independent output painting in this case? */
515	-
516	-    foreach (CompOutput *o, outputs)
517	-    {
518	-	if (o->width () != width || o->height () != height)
519	-	{
520	-	    sizeDiff = true;
521	-	    break;
522	-	}
523	-    }
524	-
525	-    if (expoCam > 0.0 && outputs.size () > 1 &&
526	-        optionGetMultioutputMode () == MultioutputModeOneBigWall &&
527	-	!sizeDiff)

> Do not force "One wall per output" on the user, if his displays use different
> resolutions.
> "One big wall" makes a lot of sense for many multi-screen configs, where not
> all of the screens have exactly the same resolution, so if the user explicitely
> chooses this mode, Compiz should respect the user's choice.

"One big wall" is currently the default behavior which makes some sense so long as the screens have exactly the same resolution. Its *completely* broken for multimonitor configurations with different resolutions. There's just no sane way to line the views up so that they look correctly when the wall is only rendered in one pass. This change should be reverted.

I even have misgivings about the way that it works on multimonitor configurations where you have the same resolution and a number of viewports that is not evenly divisible amongst the monitors. It results in confusing situations where viewports end up partially on one monitor and partially on another and does not make for a good user experience.

328	+		if      (event->xkey.keycode == leftKey)
329	+		    moveFocusViewport (-1, 0);
330	+		else if (event->xkey.keycode == rightKey)
331	+		    moveFocusViewport (1, 0);

This is alignment-formatting taken to its extreme. Alignment can sometimes aid readability but it should be used judiciously and not inflexibly. This just makes the code unreadable. There is no reason why there should be that much whitespace between an if and brackets.

358	+			 (unsigned int)optionGetDoubleClickTime ()

There should be a space between the cast or better yet a static_cast <unsigned int> ()

368	+		prevClickPoint = CompPoint(event->xbutton.x, event->xbutton.y);

Extra whitespace required.

395	+		    /* TODO: What action to take if expo_key is not defined ? */

An action is always bound to it. That's different from whether or not a keybinding is assigned. This todo is inaccurate.

449	+	const int   scw = screen->width ();

That variable should be renamed to "screenWidth" - "scw" is ambiguous.

448	+	const float mpi = M_PI / 180.0f;

This should be renamed degreesToRadians

475	+    screen->handleEventSetEnabled               (this, enable);
476	+    cScreen->preparePaintSetEnabled             (this, enable);
477	+    cScreen->paintSetEnabled                    (this, enable);
478	+    cScreen->donePaintSetEnabled                (this, enable);
479	+    gScreen->glPaintOutputSetEnabled            (this, enable);
480	     gScreen->glPaintTransformedOutputSetEnabled (this, enable);

Whitespace alignment should be applied judiciously.

640	+		CompRect input (w->inputRect ());

That can be taken by const & while you're at it.

775	+	const float sw  = (float)screen->width ();		// screen-width
776	+	const float sws = sw * sw;				// screen-width-squared
777	+	const float rs  = curveDistance * curveDistance + 0.25;
778	+	const float pcd = p1[2] - curveDistance;
779	+	const float vzs = v[0] * v[0];				// v-zero-squared
780	+	const float vts = v[2] * v[2];				// v-two-squared
781	+	const float vsv = vts * sws + vzs;

Instead of using comments consider using more descriptive variable names.

Note: This isn't a full review yet, but its what I've found so far.