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 <[email protected]> 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
