Where should project Weston go?

[Daniel Stone]

Hi,
As others said - thanks for kicking this off. I think it's pretty long
overdue. The 'release roadmap' mails I guess were meant to do this in a
way, but never really got anywhere ...

On 8 December 2014 at 12:01, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> To reiterate the main points:
> - the reference implementation
> - minimal
> - fast (performant?)
> - suitable for embedded and mobile (and now automotive?)
>

To me, 'embedded and mobile' here really just means that the user
interaction requirements with the core environment are quite limited. To
me, this is primarily defined by a negative goal: we are not, and never
will be, a desktop environment to compete with GNOME, KDE, Cinnamon,
Openbox, whatever. This turns out to be just fine for mobile, automotive,
set-top box, digital signage, etc, because while they do need a really good
compositor, they don't need wifi configuration, runtime-configurable
favourite launchers, etc, etc.

So it's less a question of Weston's, and more desktop-shell's.


> I believe it means, that Weston needs to implement all the important
> desktop-related protocol extensions, obviously starting from xdg_shell.
> This is the reference implementation. However, other desktop-oriented
> protocol extensions might not be that obvious. How would we judge them?
> I guess it has to be case by case, which makes it hard for any one
> person to do.
>

I think this has been pretty valuable, especially whilst we didn't have any
other real compositors of note. But now with Mutter being more stable and
QtWayland being infinitely more sensible in 5.x, we don't have a hard
requirement on that anymore.


> Should we add one more goal for Weston: a simple desktop environment?
> But how simple? Would it include, say, a tool to do permanent video
> mode changes? A real screen lock? A task list? Also see the note about
> "camp agnostic" below, which limits the realistic possibilities a lot.
>

A desktop environment? Please god no. A platform that people can develop
desktop environments on? Sure! I guess a lot of those would be fine as
Weston plugins, though ultimately we'd need something like libweston to
make that workable. My biggest problem with libweston as it stands is that
I think it stands to repeat the X.Org 'API' disaster: just copying all your
header files into a directory somewhere and installing a library isn't an
API. I'd like to have a much more serious look at what we expose, how, and
why.

That would be quite a bit of work, but I think far more valuable if it
allows us to get rid of large swathes of desktop-shell.


> Then again, why was IVI-shell merged? My own opinion is that IVI-shell
> serves the embedded (automotive) space. The people pushing it had a
> strong will to see it upstreamed to Weston, and I have understood they
> are committed to maintaining it. It's not just a code drop, there is
> more to come. I hope that it will also bring new contributions and new
> contributors for all over Weston, benefiting also the desktop.
>
> IVI-shell is also, for a long time or maybe ever, the first non-desktop
> shell in Weston intended for applications and not mostly for nested
> compositors like the fullscreen shell. It helps to clarify the concept
> of shell (protocol).
>

I think the same arguments apply to features you'd see in the environments
I listed above. These don't have particularly heavy requirements on things
like desktop-shell, and Weston is perfectly usable for them as a minimal,
stable, reliable, and fast compositor.


> Then what should we not put in Weston?
>
> So far Weston has been kept deliberately "camp" agnostic, which means
> that dependencies to GNOME, KDE, E or similar "camps" are not allowed.
> In practice, Weston should never even optionally depend on GTK+, Qt,
> EFL, or such. Weston does optionally depend on glib, but I suppose that
> is acceptable considering the features depending on it. It has been camp
> agnostic to not favour any particular existing DE camp, and to not
> alienate any other DE camp.
>
> I think walking that middle road has been good, and we should continue
> that.
>

I agree. I think GLib is pretty much fine, given that Qt has been depending
on it for quite some time. It doesn't handle OOM situations gracefully, but
we probably don't either. I was going to suggest that this would make it
unsuitable for some critical devices, but given that I know of medical
devices deployed using GTK+ on Wayland, I guess that boat has already
sailed. ;)


> What do you think what Weston should be in the future?
>

I think where it is at the moment is pretty much fine, but we really need
to look at desktop-shell. I'd like to see most of the shell gone, and
instead some alternative environments spring up to take the load:
environments which are actually usable, which shell.c barely is.


On 8 December 2014 at 23:26, Bryce Harrington <bryce at osg.samsung.com> wrote:

> But Weston's development processes seem to be set up more for product
> development than for freeform R&D.  Namely, we have one single "true"
> tree with a gatekeeper to control what gets committed, reviewers to
> catch quality issues, and a growing testsuite.
> I'm not saying this is wrong, just that this is probably not ideal for
> facilitating experimentation; folks may prefer to gravitate towards
> other compositor development projects where they can turn ideas and
> patches around more swiftly.  And that's not necessarily a bad
> thing... but it's different than considering weston as a test bed.


Hmm. I think our biggest problem with review is that the one-reviewer model
doesn't scale. We currently have Patchwork to address that in an ad-hoc
manner, but could we do better with more tooling? Something like Gerrit
perhaps? I don't want to give up on the review + gatekeeper model, because
while it does have its limitations (particularly whilst we only have one of
them), I really don't want to go back to the old model.

The other option is to get weston's head and heart aligned, and
> strengthen our focus on being "just" a test bed for improving the
> Wayland protocol.  Give our community's primary attention not to
> Weston's users but Wayland's users - Enlightenment, GNOME, KDE, and
> other DEs.  Survey and study their requirements and look for things they
> need across the board.  And make it easier for them to bring us their
> problems/ideas/needs.  Make it convenient for people to do prototyping
> and experimentation in Weston first, and then port to production
> compositors, rather than vice versa.  Instead of unit testing weston,
> improve the validation testing of wayland, such that the same testsuite
> would run against the weston compositor, enlightenment compositor, et al
> to verify that the DEs have properly implemented the protocol
> requirements.  Instead of delivering a monolithic Weston package, turn
> the best bits of it into specialized libraries that DEs can use too (if
> they wish).  Define a clear process for 3rd parties to contribute
> extensions, libraries, and driver support changes.  Finally, work to
> change public perception to stop the expectations on producing
> Weston-the-desktop, by vocally championing DEs that are already giving
> solid Wayland-based desktops.


This is definitely one of the better attempts at a mission statement I've
seen. I'd like to keep the caveat that Weston as-is is perfectly suitable
for the more limited environments - who usually require next to zero
interactive window management - and that having a single implementation
which is by-default usable for them is a good thing. This also makes it
_much_ easier to do validation of, e.g., drivers. But yes, I'd like to see
more parts of Weston being reused by others. It'd require a commitment to
review, documentation, API stability (ha ha) and support which has not
always been present, but if we can do that, then great.

I know from looking at patchwork lately how big of a workload this is
> for one person.  I would be more than happy to lend a hand with
> maintenance; I do maintenance on Cairo, am release manager for Inkscape
> and used to maintain the X stack for Ubuntu, so have some experience
> here.  Samsung has a strong interest in Wayland right now, so the
> maintenance work would be a day job priority.


To add to what Pekka just said (if so, great! if not, oh well): I don't
think there's any reason this needs to be a one-person thing. I found
Kristian's patch-queue-status mails to be incredibly valuable, and whilst
they really benefit from maintainer input, I don't think they're something
which needs to be held by the maintainer, and can in fact be a huge help to
a maintainer, as a signpost to bits they may have missed or need to pay
attention to. Also the others: I'd definitely read it, and if I saw 'needs
attention from an input person' or whatever flagged, go have a look at it.
If there's anything that's blocking you in any way from doing these
(Patchwork, mails, wiki, account access, patches needing review), please
make noise about it until someone does something about it.

On 9 December 2014 at 13:40, Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

> This is not to say we shold not have, say, a xdg_shell implementation.
> That is a very basic building block of a wayland desktop shell, so it
> fits perfectly there. Stuff like expose or the broken virtual desktops
> implementation, not so well, imho.


As the person who merged Exposay, I'd be a big advocate for removing it.
Ditto the virtual desktops. But in the absence of a strong external user,
they are actually really useful: Exposay ensures our transform and
animation frameworks continue to work properly, and the workspaces did a
lot for, e.g., weston_view. Both of these were really useful in terms of
Weston's development and how we implemented backends and renders, and I'm
worried that removing the two testers would break it pretty quickly. Now,
if we had people using these externally (or hey, even testcases), I would
love to see both of them removed.

On 9 December 2014 at 19:36, Jason Ekstrand <jason at jlekstrand.net> wrote:

> I think that Weston's performance matters a lot in some respects and not
> much in others.  We don't want to overcomplicate things by prematurely
> optimizing or squeezing out every clock cycle we can.  However, Weston does
> give us the opportunity to show off some of cool performance things the
> Wayland protocol allows us to do.  One example of this is the planes
> support in the drm backend.  Weston may be the only desktop compositor
> around today that take a single subsurface out of a window, put it in a
> plane, and flip it directly to the screen.  This is fantastic for
> performance and power usage and is one of the advantages of the Wayland
> protocol.  If people come to us complaining that "you can't do that in
> Wayland" just because GNOME or KWin aren't doing it, we can point to Weston
> and say, "See, yes you can, they just aren't".  Another fantastic example
> of this is the way the RPi backend uses planes.  So I think showing off
> performance things we can do thanks to Wayland is important, squeezing out
> clock cycles isn't.


This was the other reason for merging Exposay ...

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141210/c4f9101a/attachment-0001.html>