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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
