A barebone version of Weston?

[Jørgen Lind]

Hi Mikalai

On 12 July 2012 08:03, Mikalai Kisialiou <kisialiou at gmail.com> wrote:
> 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,

I think you should also have a look at QtCompositor[1]. Like Weston,
Qt has its interfaces to abstract away the input and the output. So we
used these interfaces to create a compositor API. The project has 3
very basic examples compositors which shows how you can use different
rendering techniques to make your compositor. If you have a look at
the code, it should also be easy to see how you can easily add your
special extensions if you need it.

We follow Wayland master quite close and as it speaks Wayland, any
Wayland client should be able to map its surfaces on screen.

Jørgen

[1] http://qt.gitorious.org/qt/qtwayland