Thank you, Jørgen. I will definitely look at QtCompositor. It is surprising that you release it under the BSD license. I thought that the non-commercial QT was under a modified LGPL. Anyway, it's nice to see that the QT team is not resting on its laurels and actually pursuing innovative directions like Wayland. Thanks, Nick <div class="gmail_quote">On Thu, Jul 12, 2012 at 6:59 AM, Jørgen Lind <<a href="mailto:jorgen.lind@gmail.com" target="_blank">jorgen.lind@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mikalai <div><div class="h5"> On 12 July 2012 08:03, Mikalai Kisialiou <<a href="mailto:kisialiou@gmail.com">kisialiou@gmail.com</a>> 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, </div></div>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] <a href="http://qt.gitorious.org/qt/qtwayland" target="_blank">http://qt.gitorious.org/qt/qtwayland</a> </blockquote></div>