[OE-core] [Openembedded-architecture] Future of sato and X in oe-core

Richard Purdie richard.purdie at linuxfoundation.org
Tue Feb 11 17:53:38 UTC 2020


Hi Alex,

Thanks for bringing this up.

On Tue, 2020-02-11 at 13:49 +0100, Alexander Kanavin wrote:
> I'd like to lay out a few ideas/thoughts on what should be done with
> sato (matchbox bits) and X going forward. The inputs are:
> 
> - Red Hat is the only company doing X maintenance anymore, and
> they're transitioning it to 'hard maintenance mode'
> https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
> "Once we are done with this [xwayland gaining missing features] we
> expect X.org to go into hard maintenance mode fairly quickly. The
> reality is that X.org is basically maintained by us and thus once we
> stop paying attention to it there is unlikely to be any major new
> releases coming out and there might even be some bitrot setting in
> over time. We will keep an eye on it as we will want to ensure X.org
> stays supportable until the end of the RHEL8 lifecycle at a minimum,
> but let this be a friendly notice for everyone who rely the work we
> do maintaining the Linux graphics stack, get onto Wayland, that is
> where the future is.
> "

X.Org is definitely going to be shrinking market share going forwards.
That said its going to take a few years for this to happen, its not
going to be gone in 6 or 12 months. I'd hope that it should be a
relatively low maintenance burden over the next couple of years as it
won't change much, it will mainly be things like gcc changes that will
affect it.

> - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year),
> and does not have a Wayland compositor. Yocto project does not have
> the resources to do the gtk4 port, or add a compositor.

Whilst gtk4 will come out, gtk3 will continue for a while yet, it feels
like we only just got rid of gtk2+! :)

> - no 'lightweight Wayland compositor with a desktop/launcher
> experience" has emerged in the open source space; I think the only
> realistic choice at the moment is the reference compositor Weston
> which provides a blank desktop with ability to open terminal windows.
> 
> So the way I think things should be going (seeking opinions/inputs of
> course):
> 
> - oe-core adopts Weston as the 'new sato'; all sato images that
> currently pull in matchbox and friends are changed to be Weston-
> based. Note that there is no requirement for 3D acceleration; Weston
> works with plain frame buffer device. However, both options should be
> supported and tested. Also, support for Xwayland should be tested.
> 
> - oe-core continues to support and runtime-test X for as long as
> possible; for this a new image (say, 'core-image-sato-xorg') is
> created which will provide matchbox under X. However, once upstream
> bitrot sets in, and pain threshold is exceeded, this will be removed
> and/or relegated to a legacy layer.
> 
> Thoughts?

I still strongly believe we need something in core which pulls together
all our pieces into a UI where you can test key elements of what we
build. If we don't have sato how do we actually test the core or demo
it?

I think we shouldn't rush into things here. We should ramp up our
wayland testing and make the wayland images more useful/comprehensive
and then look at moving more of our tests from sato to the wayland
images.

So in summary, yes, I think we do retarget our testing over time and
strengthen when were testing under wayland. I probably don't see that
needing to happen quite as quickly as you do though!

Cheers,

Richard











More information about the Openembedded-core mailing list