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

[Tiago Vignatti]

As you said in the other email thread, it seems that your end goal is 
more related with desktop aesthetics and building a pretty DE. Thus core 
compositor and protocol development is not the priority.

So in my opinion I'm not sure that forking Wayland/XWayland/Mesa or any 
of the projects being carried by Kristian is the answer. What you could 
aim instead is a new tree with your own shell plugin and stack over the 
core protocol another high level surface protocol (i.e. not use 
shell_surface probably), so you will be entirely free to do whatever you 
want in terms of UI. And this wouldn't be a fork in any way but the 
opposite cause would just build up Weston and related projects more -- 
I'm sure you would have to stitch these projects a bit, but the work 
there would be small most definitely. I'd like to point this blog entry:

http://vignatti.wordpress.com/2013/03/05/ui-customization-on-wayland/

in summary, the idea is to build a DE for Weston using a real toolkit 
library. I believe this is what Hawaii desktop is going towards.


But in any case I appreciate and applaud your efforts, Scott. I'm just 
not sure the way you exposed is the best way of dealing with the situation.

Tiago

On 03/25/2013 05:43 AM, Scott Moreau wrote:
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>