wayland-protocols scope and governance
jadahl at gmail.com
Thu Feb 21 17:23:06 UTC 2019
On Thu, Feb 21, 2019 at 11:47:13AM -0500, Mike Blumenkrantz wrote:
> 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.
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel