wayland-protocols scope and governance

[Daniel Stone]

Hi,

On Tue, 19 Feb 2019 at 18:36, Drew DeVault <sir at cmpwn.com> wrote:
> On 2019-02-19  4:50 PM, Daniel Stone wrote:
> >   - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan)
>
> This might start getting out of hand, I think. Here's an incomplete list
> of clients which use wlr protocols:
>
> - [...]
>
> This is just the clients I can think of off the top of my head. Consider
> also demo clients, like weston and wlroots clients. There's going to be
> a lot of clients! Something I want to avoid is making the criteria for
> inclusion in the list subjective, and if we have to decide what makes
> GLFW worth including and weston-simple-egl worth excluding, I fear
> politics will ensue.

Glibly, I'd probably just categorise the sway* clients in under the
Sway/wlroots project, unless they had separate governance, opinions,
roadmaps, etc? Similarly, I'm not sure there's much reason for us to
separate the toytoolkit and simple-* clients from Weston.

wp_* governance has a part to play here as well. Is handing
strong-veto rights to every small application the right thing to do?

> > My second suggestion is to formalise the 'xdg' namespace. xdg
> > extensions have been accepted or rejected by rough consensus between
> > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough
> > to me, assuming that 'xdg' retains the focus of an integrated (as
> > opposed to build-it-yourself) desktop.
>
> What is the criteria for having a voice in this xdg namespace
> "consensus"? This seems a bit opinionated and subjective.

Open question! It's a historical fact, for better or worse, that
xdg_shell was basically developed and released between those three
projects. Something different could definitely happen in future.

We had a 'what is XDG actually?' discussion on IRC, and seemed to
conclude that xdg_output was a misnomer and didn't belong in the
space. That it should actually be things like xdg-shell and
xdg-decoration, for app-centric and user-interaction-centric window
management, mostly but not exclusively aimed at actual desktops.
xdg-shell is obviously usable across non-desktop contexts, but
something like ivi_wm/hmi_controller definitely doesn't belong to the
XDG namespace. Better wording for the scope is super welcome.

One suggestion that came up was applying the same governance to xdg_*
as to wp_*, so it would be like 'wp_* for window management'.

> > Or Weston hasn't implemented xdg_foreign and probably won't, but I'm
> > fine with it existing and being a common extension. On the other hand,
> > Weston/Mutter/etc would have very strong opposition to a 'wp_randr'
> > extension, and last I saw wlroots would have very strong opposition to
> > wp_pointer_gestures. So those wouldn't be wp.
>
> This makes me wonder: what's the role of Weston in this? As a reference
> compositor which isn't designed for end-users, I don't think Weston has
> ever been well-positioned to be an influencer on Wayland, but should
> rather be a reflection of what Wayland is without its influence. Do you
> have any thougths on this?
>
> In other words, if Weston doesn't want to implement $protocol: so what?

I definitely have some thoughts - speaking only for myself, and not
for the Weston project as a whole. I'll open up the discussion here
since you asked, but it should probably be a separate discussion
rather than derailing this.

The role Weston plays in the overall Wayland ecosystem has certainly
changed over the years, and it's definitely in need of clarification
if not adjustment now, but I think Wayland as a whole would be quite
different, and net objectively worse, without the roles Weston has
played, despite it not having the huge userbase of GNOME/Mutter, nor
the proliferation of relatively-less-used-but-strongly-focused
projects that wlroots has.

One of Weston's goals is to be a reference compositor. As an active
implementation, it serves as a useful neutral ground for the rest of
the ecosystem: we try to be exhaustively correct in what we do
implement, and gets used as a litmus test for clients and compositors
both to compare their behaviour against (who's interpreted the spec
incorrectly?). We take that responsibility pretty seriously, which
places a ceiling on the rate of change as well as the breadth of
functionality we can implement.

There used to be a rule (observed in all but extremis) that any common
protocol had to have a Weston implementation, as the closest analogue
we had to a conformance test suite. That was abandoned long ago, since
there are some protocols for which it wasn't practical to do so. That
was the point beyond which we moved from Weston being _the_ reference
compositor for the entire ecosystem, to just being a useful resource.
(I get that Weston's README still says 'Weston is the reference
implementation of a Wayland compositor' as literally its first words.
I'd personally be OK with changing that.)

Weston is also useful as a demonstration vehicle for new low-level
graphics functionality, particularly for EGL and KMS features. We were
the first to do overlay planes, full damage tracking (and now
per-plane KMS damage tracking), dmabuf, buffer modifiers, explicit
fencing, atomic modesetting, same-CRTC clone mode (AFAIK),
aspect-ratio modes, and so on. I'm pretty happy with how that's going,
even if we do still have some feature gaps.

There are a lot of environments in which having a stable, reliable,
efficient, consistently performant, and very capable compositor, is a
perfect fit. Not just automotive, but over the years it's landed
pretty much everywhere you can think of which has a screen displaying
some kind of graphics. The debug protocol and explicit-fencing work
we've been pushing forward lately is part of a wider story to make it
possible to do end-to-end performance analysis of real workloads
running on top of Weston. That helps the people trying to build
products with real performance requirements, it helps the developers
of all the major toolkits who profile their toolkits on top of Weston
(due to the above), and it also helps the wider ecosystem by giving
one example of best practice.

I take exception to 'not designed for end users' though. desktop-shell
has 'full desktop environment' as an anti-goal, but that doesn't
discredit the usefulness of the core of Weston, any more than tinywl's
deliberately limited scope discredits the usefulness of wlroots.
That's literally the reason why we split Weston into
libweston-the-core and Weston-the-thing-that-uses-libweston. The fact
that the latter and desktop-shell aren't intended to do dynamic output
configuration or connect to your WiFi network, doesn't preclude (and
has never precluded) from someone building that environment on top of
libweston. On the contrary, we explicitly avoided that in
desktop-shell, in order to create negative space for others to come
and define their own UI rather than making Weston into its own
opinionated desktop environment.

So far those desktop users of libweston haven't eventuated. I don't
think that's anything to do with any of Weston's aims above; from what
I've seen, it's mostly because libweston is very underdocumented, has
some corners where we opted for a spiky-but-capable rather than a
friendly-but-easy API design, has some parts where we made the cut
between Weston and libweston at the wrong place, and some parts which
have clearly never been used by more than one implementation. These
are technical issues we can fix without compromising any of those aims
above. (There's also the community issue, in that it was unnecessarily
difficult to approach, communicate with, and contribute to Weston as a
project: something we've worked really hard on fixing over the past
year.)

So yes, I do think Weston has value in the ecosystem. As a personal
contributor who spends his free time on it, if the Wayland project
decided as a whole that Weston was required to have no opinion or
influence on the ecosystem and instead just serve as a note for
whatever everyone else came up with, I would just walk away from
Weston. As a Wayland developer, I'd argue against that decision, since
I think Wayland as a whole would be worse for it. With my Collabora
hat on, rather than invest our own time into the ongoing health and
development of Weston, I'd cut out the middle man and just invest our
time into writing documentation instead.

As a concrete example, most of the rest of the Wayland ecosystem has
decided to make text layout and image decoding block the compositor's
main presentation loop. Weston has deliberately avoided this, in order
to achieve the goals listed above, and it's been successful in that.
desktop-shell provides an example to others of using
intent-declarative private protocol to achieve this. People can follow
that example if they want to; there are plenty of examples of people
doing the opposite as well, which is totally fine. If the conclusion
of what you're saying is that Weston could not serve as a unique
counter-example - the wider ecosystem has decided that delegating
surface picking is a good idea and suddenly you can't do overlay
planes - then Weston becomes useless to its actual end users. If those
end users fall away, so do the developers, and the project. (Who would
want to actually work on that ... ?)

But why should Weston cripple itself in order to create this negative
space for wlroots or Mutter or Smithay or whatever? I'm happy to clean
up the README to reflect reality. One of the side effects of creating
this protocol documentation site really should be an update of the
Wayland site as a whole to reflect the actual reality of Wayland as a
project in 2019, including better and more accessible documentation,
linking to the various environments and implementations (including
linking to a separate Weston site), and, y'know, not claiming that
Weston's X11 backend uses DRI2. The entire site describes a project
which has long since moved on a long way since it was written -
including the role that Weston plays.

> How do/should the gatekeepers of Weston make these decisions?

Same way as the wlroots or Mutter maintainers do ... ? Make a
judgement on how the protocol fits with the aims and realities of
Weston as a project.

A randr protocol as has been proposed before does not meet that test
(same for Mutter). Maybe a libweston user would want to implement it.
Good for them; they're completely free to do so. That to me says that
listing that protocol under a namespace of 'everyone agrees on it, and
it's a good protocol you should use as it will work most everywhere'
is a bad idea. If you came out and said 'wlroots will never implement
idle-inhibit because $reasons', that would suggest it shouldn't be
listed in that 'uncontroversial and widespread' namespace either.

What I had in mind was something like xdg_shell, where a short and
recognisable prefix would set an expectation that the protocol was in
widespread use; that authors of new compositors should implement it to
be maximally compatible, and clients should write to it and be able to
expect it mostly works. Maybe, as Pekka said, that isn't workable and
we should scrap the idea of agreed-upon prefixes and leave it a
free-for-all.

> > Bikeshedding the prefix to use [for vetoed but still relevant
> > protocols] would be welcome, as I don't have any good suggestions
> > right now.
>
> xdg?
>
> I think gatekeeping the xdg namespace is going to allow a lot of the
> frustrating politics to thrive even with these changes, and it is a nice
> namespace for defining these standards.

XDG is already overloaded enough that I'd like not to add 'stuff some
people use but others feel very strongly about not using' to it. Some
people also interpret XDG to mean 'freedesktop.org Certified Seal of
Approval™', which is ... sort of the opposite of that.

> > Once we've established and codified these ground rules - with a
> > document along the lines of Wayland's CONTRIBUTING.md - we can open up
> > commit access to wayland-protocols, so we're not so reliant on a
> > couple of arbitrary gatekeepers. Obviously this would be done with the
> > expectation that those ground rules are followed - don't post a wp_
> > extension on a Sunday morning and then commit it in the evening with a
> > couple of +1s because no-one objected - but we're all reasonable
> > adults, and can treat each other reasonably without having to enforce
> > ACLs.
> >
> > Does anyone have any thoughts or suggestions here? Is this a good
> > aspiration? Is it the best way of achieving that aspiration?
>
> +1
>
> I don't see commit access as a magic equalizer, fwiw. I don't mind
> sending a patch along and letting someone else integrate it so long as
> they're following well-defined policies and not operating under their
> own agenda.

Right. On the other hand, I also don't want to have to gatekeep
development of protocols I have no interest in (even if it is just
clicky busywork), and even protocols I do have an interest in. If
we're lowering the barrier to entry and trying to raise our level of
inclusion, we might as well deal with the bus factor whilst we're
here.

> Another thing I'd like to clarify is the process of agreeing on the
> appropriate prefix for a protocol. Perhaps there's an experimental_ or
> draft_ namespace which has a near-zero barrier to entry (just add your
> implementation to the list), and then you can separately make your case
> for adopting it into another namespace. During the draft step you can
> pitch your protocol to interested parties, write implementations, and so
> on, which strengthens the case for including it in some namespace.
>
> Under this process, the xdg and wp and whatever else namespaces reflect
> reality, and each protocol there is known to have the support of at
> least a few implementations - rather than reflecting that at some point
> some number of people agreed it would be a good idea, and then maybe or
> maybe didn't write implementations.

To be honest, that sounds a lot like the development process we have
already. If something is expected to be under heavy development and
potentially need a lot of rework after implementation, then it can
just live in a branch and people can pull it from the MR or whatever
as they develop it in their (presumably also not merged) compositors
or clients.

I think the 'z' prefix and general unstable versioning rules work well
here. If multiple people have implemented a protocol and are sharing
it, then (taking 'ext' as a strawman for
not-wp-but-not-single-project-either) it would be zext_redshift_v1. If
single projects wanted to push something, then they could push it
under their own namespace, e.g. zmutter_animation_control_v1, but at
that point it's not really clear what benefit there is to it being in
wayland-protocols master. At that stage of development, it's probably
going to be more of a hindrance having to observe the versioning and
stability rules.

Cheers,
Daniel