Clarifying scope and goals for weston

[Sam Spilsbury]

On Wed, Apr 17, 2013 at 1:34 PM, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> Hello list,

Hey Kristian.

Thanks for taking the time to start this discussion. I'm probably not
all that qualified to make a comment here, but I will point out some
ideas and observations I've had about this.

> I see more reviews on the list now and I really appreciate that;
> thanks to Thiago for writing the email and to everybody who has jumped
> in and reviewed patches.  However, Pekka brought up a good point:
>
>    "Anyone can review coding style, but what if we massage coding
>     style and other minor details back and forth a lot, and then
>     someone does a proper subjective review NAK'ing the whole idea, or
>     at least forcing a complete rewrite. Is that review and
>     improvement work wasted for nothing, or is it useful?"

1. Patch review:

Pre-commit code review is a good development practice, but it needs to
have a quick turnaround time for contributors to feel engaged in the
process. I don't think there is a real problem with the
patches-on-the-mailing-list approach, though I might suggest moving
the project version control to a platform like GitHub where things
like pull requests make managing the queue easier for both
contributors and reviewers. I can make the case for this more
generally if people are interested, but I won't talk about it too much
now.

Something that I think should be put in the "guidelines" is a
preference for RFCs where functionality changes are being proposed.
Then we can first review the proposed changed specification, see if
the maintainers are happy with it, commit that to a specifications/
subdirectory in-tree and then work on implementing that specification
in a second review process.

> Part of the confusion around this is that weston started out as just a
> way to verify the protocol as well as gbm, KMS, evdev etc integration,
> which implies that it's throw-away code or at best a source for copy
> and paste.  On the other end of the scale, what weston is today is
> obviously a lot more than just sample code, we even have a toy desktop
> that makes it look like it's a real desktop environment.
>
> In my mind, the main output of weston is the core compositor and the
> plug-in API.  We have a very efficient GLES2 renderer, very good KMS
> integration and overlay usage, and a good input stack.  We have good
> infrastructure for writing custom backends and a flexible way to
> plug-in a higher-level shell component to handle window-manager-like
> responsiblities.  This is the part of weston I consider product
> quality and we have to maintain high standards when working in that
> area - strict error checking, handle all corner cases etc.  The core
> compositors goal is to be a base for other projects, similar to how
> the X server isn't a full desktop environment or mobile/embedded UI,
> but a core technology to build one upon.  It is also still the
> reference implementation and must implement and exercise all core
> protocol.

2. Re-use of weston functionality

Weston has a lot of really great functionality that would be useful to
lots of different desktops. I'm thinking about some of the core-stuff
like geometry / texture clipping, opaque region calculation, video
capture, damage handling, gbm etc.

This stuff is really hard to get right, and its a big ask for people
to deliver new shells on top of the wayland protocol when they have to
get all the groundwork right first. Also, the main goals of renderers
and display managers don't really differ at that much, you just want
to get it a) right and b) fast. To that end, encouraging code sharing
makes a lot of sense.

What I would suggest is that instead of a plugin model,
weston-as-a-library might make more sense. That would mean that lots
of the compositing / display handling logic can be put inside of a
libweston for other compositors to build a window manager and shell on
top of. This is basically how mutter works today (eg, libmutter).

It also means that for those projects, testing becomes a lot easier.
Testing a shell plugin is really hard to do because of the extra
dependency on the host binary, whereas desktop environments that wish
to test their window management and other logic can simply isloate the
weston library.

This proposal is a little tricky considering the implicit global
context. I would suggest at least that weston-as-a-library is not
responsible for making any OpenGL calls, but rather provides a set of
utility functions so that implementing compositors can do those calls
themselves.

The other alternative is to ask that desktop environments build on top
of weston as a shell plugin, though I suspect that could be a
controversial proposal.

Best Regards,

Sam


--
Sam Spilsbury