wayland-protocols scope and governance

[Jonas Ådahl]

On Thu, Feb 21, 2019 at 11:47:13AM -0500, Mike Blumenkrantz wrote:
> Hello,
> 
> On Thu, Feb 21, 2019 at 10:47 AM Daniel Stone <daniel at fooishbar.org> wrote:
> 
> >
> > 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.
> >
> >
> Speaking on an entirely personal level (i.e., unrelated to any project or
> employer) and as someone who has spent an amount of time writing both
> compositors and clients using Wayland protocols--and also writing those
> protocols, I found this to be very accurate. My ability to successfully
> implement protocols in compositors and clients has benefited tremendously
> over the years from the existence of Weston and its clients, even despite
> their noted shortcomings. I'll also go a step further and challenge anyone
> who has done similar work to deny having similarly benefited from Weston.

I too have spent years working on various sides of the Wayland world and
can only repeat the usefullness of weston; the library, toy desktop
envirnonment and sample clients. Both for help with understanding
interaction with lower level APIs, and for having something to compare
a protocol implementation with, and test clients on.

I think the focus on correctness, both regarding protocol implementation
and overall anchitecture (e.g. avoiding any UI rendering in the main
thread/process), as well as show casing various KMS features, and
anti-focus of end user facing features is key here.

> 
> If anything, I think devoting more time and energy to improving Weston and
> underlying layers would only serve to help the Wayland-using community.
> Better documentation and better reference code lowers barriers to entry and
> improves the ecosystem: this is something I know all too well from some of
> the projects that I've worked on.

Agreed.


Jonas

> 
> 
> Regards,
> Mike

> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel