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

[Alexander Kanavin]

Hello,

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.
"

- 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.

- 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?

Regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200211/91ed6cf4/attachment-0001.html>