wayland-protocols scope and governance

[Daniel Stone]

Hi all,
I'd like to open up a discussion on enlarging wayland-protocols to a
wider audience, with a better definition of what it contains.

Currently, wayland-protocols is a relatively small set of protocols
which were either grandfathered in from Weston, or a semi-opinionated
set of protocols that someone thinks is 'good'.

The original intent was to provide a set of 'blessed' desktop
protocols which 'everyone' would probably implement in order to
provide a coherent Wayland environment. To some extent - xdg-shell,
dmabuf, xdg-output, viewporter - this succeeded. For some others, it
failed badly - the input protocols no-one likes or has implemented,
necessitating Dorota's rewrite.

The elephant in the room is extensions like layer-shell and some of
the related extensions to build a desktop environment from a set of
disparate clients using generic APIs. Personally I think the
experience of X11 shows it's only designing for pain, and this is the
general position of wayland-protocols at the moment. But on the other
hand, those protocols aren't going away, they are in use, and having
them developed in a separate siloed community is doing us all a
disservice, since neither hand fully knows what the other is doing.
Even if we don't agree on the fundamentals of the protocol, we could
at least discuss it and try to point out some pitfalls and make some
suggestions for improvement.

A related issue is that it's hard for both application and compositor
authors to figure out what to do. There is no good 'big picture' on
how these protocols fit together, nor can people figure out which of
the competing proposals they should be using if they want to write an
application running on a given compositor, nor can compositor authors
figure out what apps want them to support. Depending on who happens to
be paying attention to the particular forum the question is asked,
they might get very different answers, depending on the point of view
of who answers.

My first, hopefully uncontroversial, suggestion: introduce a list of
compositors / compositor frameworks, as well as clients / client
frameworks, and which protocols they use and support. This would help
both application and compositor authors figure out where they should
invest time and effort. I suggest that we keep this lightweight: have
a registry of compositors / compositor frameworks / toolkits /
clients, each with a couple of named people who can speak
authoritatively for that project.

We could then allow each project to declare its support (or otherwise)
for any extension: will not ever implement, implementation not
planned, no opinion or N/A, implementation planned, implemented but
use not recommended (or limited/stubbed), implemented and recommended.
This list would be machine-parseable (XML, JSON, YAML, whatever is
easiest to fit), with a GitLab CI pipeline used to generate a
https://wayland.freedesktop.org/protocols/ website on every push,
which gave both a per-extension and a per-project support table. And
some more readable docs. I think this would be a really good entry
point and clear up a lot of confusion.

As a strawman list of projects to begin with (I'm sure there are others):
  - compositors and compositor frameworks: Chromium (Exosphere),
Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots
  - toolkits: EFL, GTK, Qt
  - media: GStreamer, Kodi, VLC, XBMC
  - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan)

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. The IVI namespace would
similarly be delegated to automotive people, and maybe we could
delegate the layer_ namespace to those developers as well.

My third suggestion is to formalise the 'wp' namespace, as core
extensions that everyone can agree on. It doesn't mean everyone needs
to implement them, but at least not have active opposition. For
example, Mutter hadn't implemented wp_viewporter for the longest time,
but also had no opposition to it being implemented - which wouldn't
block it being a 'wp' protocol. 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.

So where does that leave other extensions? My fourth suggestion is
that we look to the OpenGL/EGL/Vulkan registries: if an extension has
been vetoed from the wp_ namespace, but still had support and
implementations from multiple projects, that we still accept and
publish it under a different namespace which makes it clear that some
projects think the extension is fundamentally a bad idea, but it is
also not a compositor-specific extension. Bikeshedding the prefix to
use here would be welcome, as I don't have any good suggestions right
now.

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?

Cheers,
Daniel