Discussion:
A barebone version of Weston?
(too old to reply)
Mikalai Kisialiou
2012-07-11 01:53:27 UTC
Permalink
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.

Thanks,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120710/c2a34b92/attachment.html>
Juan Zhao
2012-07-11 06:26:56 UTC
Permalink
The sliding functionality is pretty good, I also like it.

As I know, the author of sliding functionality is also porting it to
tablet-shell for embeded system usage, could this resolve your concern
for desktop-shell?

Thanks,
Juan
Post by Mikalai Kisialiou
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
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.
Thanks,
Nick
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Jonas Ådahl
2012-07-11 06:27:53 UTC
Permalink
Post by Mikalai Kisialiou
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
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.
Thanks,
Nick
As it is now, the type of features you are talking about are mostly
implemented in a shell plugin that is loaded on start up and a shell
client that also is spawned on startup. There are currently two of
both in the weston tree right now, the desktop shell and the tablet
shell (with one plugin and one client each). The sliding stuff you saw
recently was implemented in the desktop shell client. If a platform
would want to be more minimal it could implement another shell plugin
and client without animations and other features. Backends are also
implemented this way; loaded as a plugin on startup.

If people want to implement their own wayland servers, they also don't
have to go via weston at all; not even via libwayland-server.so; even
though it would probably be easier and more convenient.

Jonas
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment.pgp>
Mikalai Kisialiou
2012-07-12 06:03:06 UTC
Permalink
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 <
Post by Christopher James Halse Rogers
Post by Mikalai Kisialiou
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
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>
Pekka Paalanen
2012-07-12 12:20:36 UTC
Permalink
On Wed, 11 Jul 2012 23:03:06 -0700
Post by 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.
End user features seems to be the ones that need most testing and are
the hardest to test, especially interactions with the desktop-shell
plugin.

To get a bare-bone Weston, you simply don't load the desktop-shell
plugin, but something else (granted, which doesn't exist yet). No need
to fork anything, just write a new shell for testing the core features.

Weston already has a testing framework, too. There are few tests, where
an additional plugin is loaded into Weston, test clients interact with
Weston, and then a fail/pass result pops out. It just needs a lot more
and better tests. You run the tests by 'make check'.

Once someone decides to make a software compositing version of Weston,
they will probably abstract compositing into the backend or some new
plugins. Then it's easy to add a dummy compositing plugin for testing
everything but graphics.

Forking Weston would only lead to an unsynchronized, dead fork, IMHO,
if the only purpose of the fork is testing. And then, it wouldn't test
Weston, it would test the fork.


Thanks,
pq
Mikalai Kisialiou
2012-07-13 06:35:04 UTC
Permalink
Pekka,

Thank you for your response. To clarify it, I am not developing another
windowing interface that will compete with Weston or QT Compositor. My
application is completely different and the open source graphics driver
stack is the likely bottleneck. I'm not even sure that Mesa/Gallium can
give me the rendering speed that I need.

Based on the responses I've received so far I think I understand now that
the client interface is a much bigger concern for the Weston developers. I
will simply clone my own copy of Weston as it exists today and will commit
bug fixes only as needed. And yes, I want to keep it relatively "dead"
because one man's dead fork is another man's stable source. ;)

Thanks,
Nick
Post by Pekka Paalanen
On Wed, 11 Jul 2012 23:03:06 -0700
Post by 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
Post by Mikalai Kisialiou
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).
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
that "regression compositor" to quickly identify if the problem stems
from
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
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_.
Post by Mikalai Kisialiou
The above example uses the compositor as a _tester_ with predefined
composite screen objects.
End user features seems to be the ones that need most testing and are
the hardest to test, especially interactions with the desktop-shell
plugin.
To get a bare-bone Weston, you simply don't load the desktop-shell
plugin, but something else (granted, which doesn't exist yet). No need
to fork anything, just write a new shell for testing the core features.
Weston already has a testing framework, too. There are few tests, where
an additional plugin is loaded into Weston, test clients interact with
Weston, and then a fail/pass result pops out. It just needs a lot more
and better tests. You run the tests by 'make check'.
Once someone decides to make a software compositing version of Weston,
they will probably abstract compositing into the backend or some new
plugins. Then it's easy to add a dummy compositing plugin for testing
everything but graphics.
Forking Weston would only lead to an unsynchronized, dead fork, IMHO,
if the only purpose of the fork is testing. And then, it wouldn't test
Weston, it would test the fork.
Thanks,
pq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120712/c71c89b2/attachment.html>
Pekka Paalanen
2012-07-13 07:28:31 UTC
Permalink
Hi Nick,

On Thu, 12 Jul 2012 23:35:04 -0700
Post by Mikalai Kisialiou
Pekka,
Thank you for your response. To clarify it, I am not developing another
windowing interface that will compete with Weston or QT Compositor. My
If by windowing interface you mean a Wayland compositor, there is
nothing wrong in trying to write a "competing" compositor. In fact, it
is encouraged, if you for any reason cannot or do not want to
contribute to existing ones. Diversity gives more testing to the Wayland
design, and Weston was never meant to be the only compositor.
Post by Mikalai Kisialiou
application is completely different and the open source graphics driver
stack is the likely bottleneck. I'm not even sure that Mesa/Gallium can
give me the rendering speed that I need.
If you are going to apply Wayland on a completely different use case, I
think it would be interesting to hear about it. Even if it is something
that could never be even considered for upstreaming.
Post by Mikalai Kisialiou
Based on the responses I've received so far I think I understand now that
the client interface is a much bigger concern for the Weston developers. I
will simply clone my own copy of Weston as it exists today and will commit
bug fixes only as needed. And yes, I want to keep it relatively "dead"
because one man's dead fork is another man's stable source. ;)
Considering that even the very first version of the Wayland core
protocol is not quite stable yet, yes, the interfaces are being
concentrated on. And to my knowledge, shell interfaces (which provide
window management) are not even considered core at this time.

It is quite hard to discuss this in general terms, we don't know what
you are aiming for. If we knew, we could probably give more useful
responses.


Thanks,
pq
Jørgen Lind
2012-07-12 13:59:35 UTC
Permalink
Hi Mikalai
Post by 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,
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
Mikalai Kisialiou
2012-07-13 06:14:01 UTC
Permalink
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
Post by Jørgen Lind
Hi Mikalai
Post by 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
Post by Mikalai Kisialiou
can be considered barebone since the code base is small. The question is
how
Post by Mikalai Kisialiou
long it will stay that way, given some interest from Canonical to
integrate
Post by Mikalai Kisialiou
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).
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
whose job is _not_ to composite but to _test_ functionality and speed of
the
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
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_.
Post by Mikalai Kisialiou
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
Post by Mikalai Kisialiou
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120712/91dc4799/attachment.html>
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0003.pgp>
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0004.pgp>
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0006.pgp>
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0007.pgp>
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0010.pgp>
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0011.pgp>
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0012.pgp>
Christopher James Halse Rogers
2012-07-11 10:59:56 UTC
Permalink
Post by Mikalai Kisialiou
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
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0016.pgp>
Loading...