Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

[Scott Moreau]

Ok, I admit it, you caught me. As much as I tried to say it isn't, it
is. GH Next was a preliminary code name for the patches housed on the
'next' branches of wayland/weston in github. However, it is now
officially a fork at the request of Kristian Høgsberg.

<krh> soreau: it's a fork
<krh> have the guts to call it what it is

<krh> soreau: I think it's time you pick a name for you project
<krh> start an irc channel for it
<krh> and go there

This does not accurately represent the entirety of what was said but
these are the key bits relevant to this discussion. I do not intend
this as an unfriendly fork. I was hoping that the idea of gh next
would be embraced by the core wayland developers but it was not
unfortunately. I was asked by Kristian to pick a different name for
these efforts. This is well within reason to avoid confusion, for the
time being. I will now shed some light on why I feel this fork is in
fact a necessary requirement to further wayland development.

History repeats itself. It is a known fact. This is the case now, as
was the case with compiz. I personally have been learning  how to use
Linux since a few months before compiz exploded onto the Linux Desktop
in '05. I was totally blown away by what I saw my lowly computer
doing.

Compiz was the very first popular X window manager to allow for
amazing quality accelerated effects on the Linux Desktop. Compiz
development was originally started by a company called Novell, in
2005. This task at hand has largely insane, however Novell employed
mastermind David Reveman to make the compiz magic happen. It exploded
onto the Linux desktop scene. Not only could you do accelerated
effects, but the possibilities grew exponentially. This excited a
large group of people. Reveman did all of the original compiz work
including but not limited to:

- The original XGL implementation (which was later discarded in favor
of Høgsberg's AIGLX)
- Original compiz work on mplayer (to get it working correctly with
the new extensions required to do compiz compositing properly with xv
video playback)
- Work on GLX_EXT_texture_from_pixmap (the core extension required to
run compiz)
- xwinwrap (have movies or screensaver as your desktop wallpaper)
- many of the core compiz plugins ('desktop cube' is the very essence
and iconic symbol of compiz)
- compiz itself (maintained for several years)

Reveman was crazy - but in a good way. He was the mastermind that
developed an intimate understanding of X over time, which is the other
key component besides the required graphics driver knowledge to
develop the specifications. I have followed the compiz project very
closely since its inception. I noticed that there was a major
communication problem because davidr would only communicate through
IRC once in a blue moon, on a specific network on a specific
suse-specific channel. He would schedule a meeting with someone[TM]
who would then notify the community compiz devs about the time of the
IRC session. If any member wanted to ask a question, they would have
to make their schedule fit around this time frame. Clearly, this not
an optimal way to communicate.

Frustrated by the situation and knowing what compiz was capable of,
the community forked Compiz into a project called Beryl around 2006
(this might not be the exact date, however it's not relevant to the
point I am making here). After the fork, there was a huge flamewar and
many hurtful things were said. Over the course of a year or two, the
projects were simultaneously developed in tandem. The final outcome
was that eventually the two projects came to an agreement. Compiz and
Beryl merged to form Compiz Fusion. Over time, the Fusion name was
dropped and we were left once again with Compiz, only this time with
tons more effects (plugins) and decorations (emerald). Some may
remember Beryl but it's name did not live on. The code that was
developed by the community members under this project name does live
on however. You can still see traces of beryl in the official upstream
compiz repositories.

After compiz was 'done', it was solid and worked great. Distros
packaged it an everyone was happy. Awesome Desktop Effects on Linux -
check. We're done, game over, right? Unfortunately, this is not the
end of the compiz story.

The original compiz implementation is written in C. At the very end of
2008, 12/24, Compiz++ was unveiled. Compiz++ was a C++ version of
compiz that was intended to be more easily maintainable.
Unfortunately, all of the plugins had to be ported. The majority of
this work was done by an aspiring college student, Sam Spilsbury.
Eventually, Canonical realized that they wanted to do Unity but didn't
really have the manpower required to do something entirely original.
instead, the ployed to use compiz as a base platform for their Unity
implementation. To this day, I still do support in #compiz. These
days, it's mostly complaints about how 0.9.x is broken in fundamental
ways that make the desktop unusable. Canonical severely damaged the
compiz image with their disruptive and ever-so-misleadingly-named,
Unity idea. Now, users are completely confused as to why compiz no
longer works and why the stable version remains unpackaged and unused
by distributions.

It is noteworthy, that the original C implementation still works great
to this day. The latest version is 0.8.9 and it can be found in the
compiz-0.8 branches of compiz master. If anyone wants to help the
compiz situation immediately, please go get this code and package it
for ubuntu cgit.compiz.org http://wiki.compiz.org/Installation/Stable
as many users will appreciate it. I know I would.

Now fast-forward to wayland. The #1 top thing that excited me about
wayland is the fact that the project leader Kristian Høgsberg, was on
irc and regularly available. I knew wayland offered better solutions
to certain problems, but that is nearly second in importance to a
responsive, active project maintainer. Unfortunately, even though krh
is available and does respond, he is still extremely busy and
sometimes simply does not have the time to review every piece of code
that hits the wayland-devel mailing list. Clearly, it's unreasonable
to assume that one person can do this job alone. It is nice to see
community review but this process is often not well directed and seem
to many times lose site of the big picture. Initially when I started
on wayland, I was under the impression that there was an understood
goal to create many of the popular compiz effects in weston. However,
this is apparently not the case as this is not happening. Kristian has
explained that becoming a DE is a specific non-goal of wayland/weston.
Fortunately, most compiz effects are not DE-like but even a
non-composited desktop requires basic functionality to do anything.


The names for the newly forked project that I have chosen are
Norrthfield and Norwood. These are also towns in Massachusetts, as are
Wayland and Weston. The concepts, ideas and code for Northfield are
nearly identical to that of Wayland/Weston, so I think these names are
fitting. I will now explain the differences between Northfield and
Wayland. The primary distinction is that their immediate goals are
slightly orthogonal.

What Northfield *is*
- A project to learn about compositors and think about new compositing concepts
- A place for the community to openly discuss and contribute to the project
- A place to create new and exciting desktop effects
- An environment that encourages learning about the Linux Desktop,
programming and wayland/northfield.
- An environment that is less restrictive and encourages uninhibited
free-flow thinking
- A project that aims to get as many compiz effects as possible,
working in a wayland compositor

What Northfield *is not*
- A fork that will change protocol in fundamental ways that diverts
from the wayland EGL spec
- A project that aims to cause divisions in the community or the Linux
Desktop code
- A project that breaks core wayland protocol in unrepairable ways
- Diverting significantly from wayland
- An unfriendly 'takeover'
- Unnecessary

The key point to understand is, that this is not a new protocol in its
own right. It *is* the wayland protocol, with a few minor additions
that make it possible to do new interesting things. It uses the same
EGL drivers in Mesa implementing the wayland-egl specification. This
will not change. Northfield will always use the same driver stack as
wayland. The difference is, that I now have the time to dedicate to
being a (hopefully very) responsive maintainer.

Regarding the Northfield development process:

I am making it my own personal goal to acknowledge patches within 24
hours from the time of submission. This acknowledgement will indicate
a clear 'yes' or 'no' as to whether or not the patch(es) are desired
for inclusion to the relevant repositories. In either case, I will try
to include a clear reason for 'no' or possible additional comments for
'yes'.

Northfield/Norwood is not particularly interested in changing or
working on core wayland. It is primarily focused on creating new
desktop effects for the now-forked weston. The hope is, that many
people will respond to this call and use this as a fertile and
exciting environment for developing new effects. Eventually, I would
like to see some of the better concepts resulting from
Northfield/Norwood, merged back upstream in some form. This project is
theoretically disposable, and I'd like to view it as such from the
outset. My ultimate goal is to work on Northfield until we have
absolutely incredible desktop effects. In other words, I will not stop
until I see the results that I am satisfied with. My standards are
fairly high. We want something that is just as good if not better than
compiz.

Another inherent goal of Northfield, is to make weston fit for
everyday use. I want to see things happen in Wayland/Weston, I don't
necessarily want to see this fork. However, since this has become
readily apparent, I feel this fork is entirely pertinent for the
benefit of everyone collectively.

Again, to make it clear, Northfield only adds some very basic and
necessary protocol that does not exist in Wayland, such as minimize.
It is the same in every other way except the new name.

Initially, my intent with #wayland-dev and gh next was a friendly poke
toward core wayland developers, to regroup and refresh development
efforts. I figured after the Mir announcement, that wayland
development would pick up for wayland/weston significantly. Instead,
there was a long two week period of no commits. This was surprising to
me but not very impressive either. As stated in previous emails, I
have tried to work with wayland developers over the past solid year.
My goals have been to introduce compiz-like effects into weston, the
official reference wayland compositor implementation. So far, I've
only had one effect that I consider a significant compiz effect,
upstreamed to weston. That effect is the 'zoom' feature we know as
'Enhanced Desktop Zoom' or 'ezoom' in compiz and there is now a basic
zoom implementation in weston by default. I have plans to do other
compiz effects in a wayland compositor as well, including but not
limited to:

- Desktop Cube
- Desktop Wall
- Scale (expose effect)
- Wobbly Windows
- Expo
- Emerald Theme Support

These effects can be extremely difficult to implement but they're
certainly doable. Besides, I like a good challenge. Since compiz, many
implementations have created various clones of these effects in other
X window managers. To this date, we are nowhere close to having
anywhere near the number of compiz-syle effects in weston or any
wayland compositor for that matter. Wolfenqt was a very cool
compositing effort but I don't feel that it's entirely practical as a
workable desktop for obvious reasons. The point is, that there are
people out there and right here that want to see cool things happen in
a wayland compositor but might be put-off by the wayland review
process.

Additional goals of Northfield:

- Real Time On-The-Fly Configuration (think Compiz Config Settings Manager)
- Other real time configuration such as output configuration, desktop
wallpaper switching, etc.
- Creating an environment fit for everyday use

Help Wanted:

I have server space now but I'm not too great at web-stuff. If anyone
is interested in setting up a basic site on the server, this would be
a great help. I will get it done eventually, but web-stuffs are an
automatic back-burner-pot for me. The site intends to house build
instructions, pics/videos and other project-specific information. So
far, we just have an IRC bot that monitors the repositories. Contact
me if you're interested in helping on this front.

With that, I would like to make a call to anyone who would like to
contribute toward efforts of creating awesome compiz-like effects in
this new now-forked version of weston to join in. Over the course of
the next (.us) summer, we will be working on interesting and cool new
effects. Many of these deal directly with code using The OpenGL® ES
Shading Language. If you are interested in trying your hand at
developing a new effect using GLES2 shaders in weston, I am interested
in what ideas you might have to offer. Patches and all other
contributions welcome.

Contact Info:

- oreaus at gmail.com
- #northfield on irc.freenode.net
- github.com/soreau

New Repositories:

https://github.com/soreau/northfield (i.e. wayland)
https://github.com/soreau/norwood (i.e. weston)


Building:

Grab the 'next' branches of these two repositories. The rest of the
stack is the same.

Bugs:

We don't want to ever have any bugs but of course, there will always
be bugs. If you find a bug, let us know or fix it and submit a patch.
Your attention to detail is appreciated. I will try and make an effort
to voice when I notice a patch that might be an upstream candidate,
for potentially more serious matters. Conversely, I will try to keep
site of a possible later re-merge which means not breaking the core
code in problematic ways. For Northfield/Norwood-specific bugs, please
report them to https://github.com/soreau/northfield/issues

A note about Mesa:

Mesa is a moving living thing. It is not an ordinary project by any
means. Mesa is the very core of wayland-egl and currently is the only
way it is possible to use EGL in an accelerated wayland compositor.
Unfortunately, it is broken regularly in many ways. We need to pay
special attention that mesa does not become broken to a state that
makes wayland compositors unusable. As of this date, mesa is broken
for wayland clients. See
https://bugs.freedesktop.org/show_bug.cgi?id=62663 I will try to keep
a last-known-working copy of mesa in github next branch. It is vitally
important, that mesa is not broken, if we want to do anything useful
with accelerated wayland-egl drm backend. If you see that it is not
working for you, please file a bug report or comment on existing
relevant reports, saying that you are affected too.

A note to Kristian:

Kristian, I want you to know that I think you are an incredible
developer and I have nothing but respect for you and all of your
works. I hope you understand that this is nothing *against* anyone or
anything, instead it's *for* everyone and everything. I also would
like to see you embrace these efforts and offer suggestions for things
you might like to see in weston. The community is a powerful resource
that should not be neglected. I would like this to be accepted as a
friendly effort to help make weston more fun to use, but first, usable
at all. So all things said, let the games begin! :-)

Q&A:

Q: Wont this cause more diversity in the community?
A: I hope not significantly. It will provide an outlet for some and
might possibly cause some minor disruptions. This is mostly an
underground project at this point so it's actual effects are TBD. The
important part is, that the code will be developed with a future
re-merge in mind. It will not diverge into using any driver
implementation other than the one wayland uses. Perhaps it will come
to stand on its own as a new wayland compositor, but not a new core
protocol as is the case with Mir.

Q: Why can't you just work on things in your repositories and submit
them to the mailing list when they are ready?
A: This is what I've been doing for the past several months and it
works, except when the patches remain stagnant after hitting the list.
Basically, there are a few(+) things needed to get weston/norwood fit
for everyday usage. Weston's intent is not that of a Desktop
Environment but it really already is, save a little polish and
finishing touches.

Q: Why are you going against wayland devs?
A: We're not. This projects' goals are about forwarding the wayland
project as a whole.

Q: But why are you doing this at all?
A: Several reasons. 1) It's a fun project 2) It might cause useful
things to happen 3) It might help give me a taste of what project
management feels like 4) Linus Torvalds wants to see Linux take over
the Desktop platform as the understood worldwide default operating
system. We are never going to get there if our desktop sucks.

Q: Are you nuts?
A: Yes, I am a little crazy. But you need to be in order to be
interested in compositing environments at the level I am.



I would like to thank all the developers involved and the core
community that represents the greater good force in the world, for
making this possible.



Sincerely,

Scott Moreau