A barebone version of Weston?

[Mikalai Kisialiou]

Juan, Jonas and Christopher,

I appreciate your feedback! Small additions to shells are indeed not a
problem. It was not a right example to make my point. As it is now, Weston
can be considered barebone since the code base is small. The question is
how long it will stay that way, given some interest from Canonical to
integrate it into Ubuntu QQ or RR (hopefully QQ) and potentially other
distros.

Please, let me give you another example of what I'm trying to do (without
going into application specifics that you are unlikely to be interested in).

Suppose that you want to develop your own Wayland compliant server
(W-server) that can render in 3D. Due to renderer's complexity you
anticipate that the compositor will grow quite a bit and that will pose
significant problems for future testing.

So, before you start out, you want to set up another very simple compositor
whose job is _not_ to composite but to _test_ functionality and speed of
the graphics driver stack, X as a client, some other hardware, client's
compliance to Wayland protocol, and so on. The purpose of such a W-server
is to have a regression system that checks dependent
_libraries_and_drivers_ rather than your 3D compositor. If something goes
wrong with client's rendering (e.g. too slow, visual artifacts) you can use
that "regression compositor" to quickly identify if the problem stems from
some upgraded or buggy drivers. This will save you a lot of debugging
effort and time.

The barebone version of Weston is the perfect candidate for the "regression
compositor". It doesn't need several full featured clients or shells to
minimize risk of injecting bugs. It only needs to include the minimal
architecture plus a set of driver/library test codes. It does need to be
relatively stable and up-to-date with the latest Wayland protocol changes
and some critical bug fixes though.

I hope the above example illustrates one of several potential applications
for the barebone compositor. The point here is not to get rid of useful
features from Weston. They are surely needed when I use Weston as a _user_.
The above example uses the compositor as a _tester_ with predefined
composite screen objects.

Does it make sense or am I making things more complicated than they should
be?
Thanks,

Nick


On Wed, Jul 11, 2012 at 3:59 AM, Christopher James Halse Rogers <
christopher.halse.rogers at canonical.com> wrote:

> On Tue, 2012-07-10 at 18:53 -0700, Mikalai Kisialiou wrote:
> > There is an article on http://www.phoronix.com that there is a new
> > feature of sliding desktop support in Weston. I am wondering if it
> > would make sense to split Weston implemention into 2 distinct ones: a
> > barebone implementation with minimal features (architecture + driver
> > compatibility) and a full-featured version?
> >
> > I am not saying that the sliding desktop is somehow a bad idea (it is
> > a great idea). I do love this feature and will definitely like to see
> > it on my desktop. My concern, however, is slightly different:
> >
> > Some people may look at potential opportunities to implement their own
> > version of a Wayland-compliant server. These people will likely be
> > from different areas and seek some kind of a "Hello world" version of
> > a Wayland compliant server. The applications may range from low-power
> > portable devices with limited performance to powerful CAD
> > workstations stacking dual graphics card firepower. Because
> > the requirements and expectations for the graphics interface on
> > such systems are vastly different, I am afraid that a W-server that
> > aims to be one-size-fits-all may end up being one-size-fits-none. As
> > optional features start propagating into Weston it will grow
> > into something similar to another X-server, and we are going to be
> > back to square 1.
> >
> > I understand that there will be some overhead involved for developers
> > to maintain 2 branches. However, most features will probably not fall
> > into the barebone version, so the commits for new cool features would
> > still be limited to 1 branch only. Bug fixes will indeed be harder to
> > commit. Can the 2nd full-featured branch be a library on top of the
> > barebone architectural version?
> >
> > Also, is there some sort of a policy or a decision making process as
> > to what gets committed into Weston? What do the main developers think
> > about 2 branches? I just thought I'd raise these concerns before a
> > whole list of optional features gets committed into Weston.
>
> As long as it's restricted to the shells and anything under clients/ I
> don't think it matters how much functionality is folded into weston.
> Indeed, it's probably valuable, as it helps ensure the core weston &
> wayland code can support such use.
>
> Eventually it might become sufficiently big to do a source split, but
> that seems a way off.
>
> I agree that there needs to be a higher bar than “chuck it in” for
> commits touching the core weston compositor, but I don't think I've seen
> any commits overstepping reasonable bounds there.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/9b1a320f/attachment-0001.html>