Future of sato and X in oe-core

Future of sato and X in oe-core

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2994 bytes --]

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

[Adrian Bunk]

On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
>...
> - 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 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?

matchbox made sense at a time when you could go into a shop and buy an
internet tablet with Linux running on 256 MB flash with 256 MB RAM.

Part of the problem is that the only remaining usage of this branch
of matchbox development seems to be as example UI for Yocto.

For matchbox/sato I am wondering whether replacing it with parts of
meta-xfce from meta-openembedded would be a good way forward.

Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland 
support, but at the point where supporting X might become a problem
this should be available.

Xfce was my first thought as replacement since it appears to be 
well-maintained in meta-openembedded, no strong opinion whether
it is actually the best option.

> Regards,
> Alex

cu
Adrian

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]

The question is: what are the use cases for an 'example/reference UI'? Why
have one at all at this point? Remember, the core project is severely
under-staffed and we need to commit our limited resources wisely.

Alex

On Tue, 11 Feb 2020 at 14:53, Adrian Bunk <bunk@stusta.de> wrote:

> On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
> >...
> > - 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 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?
>
> matchbox made sense at a time when you could go into a shop and buy an
> internet tablet with Linux running on 256 MB flash with 256 MB RAM.
>
> Part of the problem is that the only remaining usage of this branch
> of matchbox development seems to be as example UI for Yocto.
>
> For matchbox/sato I am wondering whether replacing it with parts of
> meta-xfce from meta-openembedded would be a good way forward.
>
> Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
> support, but at the point where supporting X might become a problem
> this should be available.
>
> Xfce was my first thought as replacement since it appears to be
> well-maintained in meta-openembedded, no strong opinion whether
> it is actually the best option.
>
> > Regards,
> > Alex
>
> cu
> Adrian
>

[-- Attachment #2: Type: text/html, Size: 2667 bytes --]

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2579 bytes --]

Specifically (sorry for the rapid-followup), I think the main value
proposition of core is integration and testing of various language
toolchains and core libraries. UIs in embedded space can mean pretty much
anything, and so I'd leave that to specialised layers.

Alex

On Tue, 11 Feb 2020 at 14:57, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> The question is: what are the use cases for an 'example/reference UI'? Why
> have one at all at this point? Remember, the core project is severely
> under-staffed and we need to commit our limited resources wisely.
>
> Alex
>
> On Tue, 11 Feb 2020 at 14:53, Adrian Bunk <bunk@stusta.de> wrote:
>
>> On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
>> >...
>> > - 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 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?
>>
>> matchbox made sense at a time when you could go into a shop and buy an
>> internet tablet with Linux running on 256 MB flash with 256 MB RAM.
>>
>> Part of the problem is that the only remaining usage of this branch
>> of matchbox development seems to be as example UI for Yocto.
>>
>> For matchbox/sato I am wondering whether replacing it with parts of
>> meta-xfce from meta-openembedded would be a good way forward.
>>
>> Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
>> support, but at the point where supporting X might become a problem
>> this should be available.
>>
>> Xfce was my first thought as replacement since it appears to be
>> well-maintained in meta-openembedded, no strong opinion whether
>> it is actually the best option.
>>
>> > Regards,
>> > Alex
>>
>> cu
>> Adrian
>>
>

[-- Attachment #2: Type: text/html, Size: 3387 bytes --]

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

[Josef Holzmayr]

Howdy!

On Tue, Feb 11, 2020 at 02:57:48PM +0100, Alexander Kanavin wrote:
> The question is: what are the use cases for an 'example/reference UI'? Why
> have one at all at this point? Remember, the core project is severely
> under-staffed and we need to commit our limited resources wisely.

My $.02 are, that while being a good test vehicle to build for us, it is
actually giving a wrong impression to newcomers. Like "here is a DE to
start off, and you can use this build like your desktop box" which is not
at all true.

So my votes are on, as long as we have something that *can* do
*something* on screen with as little effort as possible, we should go
for it. Maintaining a custom thing should be avoided.

Greetz

> 
> On Tue, 11 Feb 2020 at 14:53, Adrian Bunk <bunk@stusta.de> wrote:
> 
> > On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
> > >...
> > > - 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 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?
> >
> > matchbox made sense at a time when you could go into a shop and buy an
> > internet tablet with Linux running on 256 MB flash with 256 MB RAM.
> >
> > Part of the problem is that the only remaining usage of this branch
> > of matchbox development seems to be as example UI for Yocto.
> >
> > For matchbox/sato I am wondering whether replacing it with parts of
> > meta-xfce from meta-openembedded would be a good way forward.
> >
> > Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
> > support, but at the point where supporting X might become a problem
> > this should be available.
> >
> > Xfce was my first thought as replacement since it appears to be
> > well-maintained in meta-openembedded, no strong opinion whether
> > it is actually the best option.
> >
> > > Regards,
> > > Alex
> >
> > cu
> > Adrian
> >

> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


-- 
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

[Adrian Bunk]

On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote:
> Specifically (sorry for the rapid-followup), I think the main value
> proposition of core is integration and testing of various language
> toolchains and core libraries. UIs in embedded space can mean pretty much
> anything, and so I'd leave that to specialised layers.

That's actually quite different from your original email.

Your original email raised the problem that X might start to bitrot
after the end of support for RHEL 8 in the year 2029 (sic).

What functionality should be in core for users/demo/QA/...
is not strictly related to X versus Wayland.

> Alex

cu
Adrian

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

X might and likely will start to bitrot sooner for those not using RHEL 8
and its very conservative and never changing software stack. I can imagine
Red Hat has no interest in supporting it on Fedora going forward for
instance, they'll just make Xwayland work, and rip the standalone server
and its drivers and libraries out.

Oe-core will have X for as long as the burden of fixing build errors and
runtime issues with custom patches is not too painful. The point I am
trying to make is that I am not convinced oe-core needs a 'real' ui at all,
and opinion to the contrary should justify the need.

Alex

On Tue, 11 Feb 2020 at 15:13, Adrian Bunk <bunk@stusta.de> wrote:

> On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote:
> > Specifically (sorry for the rapid-followup), I think the main value
> > proposition of core is integration and testing of various language
> > toolchains and core libraries. UIs in embedded space can mean pretty much
> > anything, and so I'd leave that to specialised layers.
>
> That's actually quite different from your original email.
>
> Your original email raised the problem that X might start to bitrot
> after the end of support for RHEL 8 in the year 2029 (sic).
>
> What functionality should be in core for users/demo/QA/...
> is not strictly related to X versus Wayland.
>
> > Alex
>
> cu
> Adrian
>

[-- Attachment #2: Type: text/html, Size: 1826 bytes --]

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

[Adrian Bunk]

On Tue, Feb 11, 2020 at 03:35:03PM +0100, Alexander Kanavin wrote:
> X might and likely will start to bitrot sooner for those not using RHEL 8
> and its very conservative and never changing software stack. I can imagine
> Red Hat has no interest in supporting it on Fedora going forward for
> instance, they'll just make Xwayland work, and rip the standalone server
> and its drivers and libraries out.

There are plenty of other users big and small left, and most of the
hardware support already moved to the kernel.

Stale and stable is not necessarily bad for users, and X will not
suddenly stop working.

> Oe-core will have X for as long as the burden of fixing build errors and
> runtime issues with custom patches is not too painful.

If this is true, then let's revisit this topic in 10 years.

And the solution would then likely be to switch from matchbox/sato
to some desktop environment that supports wayland.

> The point I am
> trying to make is that I am not convinced oe-core needs a 'real' ui at all,
> and opinion to the contrary should justify the need.

The point I am trying to make is that this is a different discussion.

And any "no UI in oe-core" decision would not have to wait until the 
point in the distant future when X might no longer be supportable.

> Alex

cu
Adrian

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

[Mark Hatle]

On 2/11/20 8:01 AM, Alexander Kanavin wrote:
> Specifically (sorry for the rapid-followup), I think the main value proposition
> of core is integration and testing of various language toolchains and core
> libraries. UIs in embedded space can mean pretty much anything, and so I'd leave
> that to specialised layers.
> 
> Alex
> 
> On Tue, 11 Feb 2020 at 14:57, Alexander Kanavin <alex.kanavin@gmail.com
> <mailto:alex.kanavin@gmail.com>> wrote:
> 
>     The question is: what are the use cases for an 'example/reference UI'? Why
>     have one at all at this point? Remember, the core project is severely
>     under-staffed and we need to commit our limited resources wisely.

I don't think an example/reference UI is useful -- OTHER THEN -- we need a way
to test that the framework(s) that are provided are functional.  So lets, assume
Wayland/Weston combo..  we still need something that can use the mouse, show
that the cursor is being drawn properly, clicks are registered, etc etc etc..

I do think that we need to include a graphical framework (X.org, wayland/weston
combo, etc..) as well as a basic set of examples that can be used to verify that
they are working properly.

There is a secondary 'problem' which I see more as a business issue then a
technical one, everyone wants to have a way to 'demo the OpenEmbedded'.  It's
pretty hard to demo a build system, so they like to have a device that boots
quickly and goes to something graphical that shows it's "working".

--Mark

>     Alex
> 
>     On Tue, 11 Feb 2020 at 14:53, Adrian Bunk <bunk@stusta.de
>     <mailto:bunk@stusta.de>> wrote:
> 
>         On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
>         >...
>         > - 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 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?
> 
>         matchbox made sense at a time when you could go into a shop and buy an
>         internet tablet with Linux running on 256 MB flash with 256 MB RAM.
> 
>         Part of the problem is that the only remaining usage of this branch
>         of matchbox development seems to be as example UI for Yocto.
> 
>         For matchbox/sato I am wondering whether replacing it with parts of
>         meta-xfce from meta-openembedded would be a good way forward.
> 
>         Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
>         support, but at the point where supporting X might become a problem
>         this should be available.
> 
>         Xfce was my first thought as replacement since it appears to be
>         well-maintained in meta-openembedded, no strong opinion whether
>         it is actually the best option.
> 
>         > Regards,
>         > Alex
> 
>         cu
>         Adrian
> 
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 

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

[Mark Hatle]

On 2/11/20 8:35 AM, Alexander Kanavin wrote:
> X might and likely will start to bitrot sooner for those not using RHEL 8 and
> its very conservative and never changing software stack. I can imagine Red Hat
> has no interest in supporting it on Fedora going forward for instance, they'll
> just make Xwayland work, and rip the standalone server and its drivers and
> libraries out. 

X is incredibly stable code base.  I think as long as there are no major
changes, the bitrot will be 'minor'.  I'm more worried about security response,
especially as it goes longer and longer with only a small set of maintainers of
last resort.

> Oe-core will have X for as long as the burden of fixing build errors and runtime
> issues with custom patches is not too painful. The point I am trying to make is
> that I am not convinced oe-core needs a 'real' ui at all, and opinion to the
> contrary should justify the need.

It's already OE's responsibility to fix build errors and integration run-time
issues.  When the burden goes beyond our resources, then we need to stop or find
a champion who will taker that burden.

I think we need to plan for that for all of the components of the system, not
just X, but X is a good starting point.

I also don't think oe-core itself needs a 'real' UI, and as my previous response
said -- we do need something though to test that the graphical framework is
working properly.

In the past this often comes back to needing a LOT of a UI in order to
adequately test all of the components of the system.   If wayland/weston has a
proper test suite that exercises all of the various parts of and pieces of the
systems -- then the need for a UI drops considerably.

(but we still have the need for some sort of example/demostration...)

--Mark

> Alex
> 
> On Tue, 11 Feb 2020 at 15:13, Adrian Bunk <bunk@stusta.de
> <mailto:bunk@stusta.de>> wrote:
> 
>     On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote:
>     > Specifically (sorry for the rapid-followup), I think the main value
>     > proposition of core is integration and testing of various language
>     > toolchains and core libraries. UIs in embedded space can mean pretty much
>     > anything, and so I'd leave that to specialised layers.
> 
>     That's actually quite different from your original email.
> 
>     Your original email raised the problem that X might start to bitrot
>     after the end of support for RHEL 8 in the year 2029 (sic).
> 
>     What functionality should be in core for users/demo/QA/...
>     is not strictly related to X versus Wayland.
> 
>     > Alex
> 
>     cu
>     Adrian
> 
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On Tue, 11 Feb 2020 at 16:58, Mark Hatle <mark.hatle@kernel.crashing.org>
wrote:

>
> I also don't think oe-core itself needs a 'real' UI, and as my previous
> response
> said -- we do need something though to test that the graphical framework is
> working properly.
>
> In the past this often comes back to needing a LOT of a UI in order to
> adequately test all of the components of the system.   If wayland/weston
> has a
> proper test suite that exercises all of the various parts of and pieces of
> the
> systems -- then the need for a UI drops considerably.
>
> (but we still have the need for some sort of example/demostration...)
>

Wayland/weston do have test suites, neither of which we currently use. I
don't know how much they exercise all the moving parts, but the tests do
exist.

As for the demo/examples, I think we have reached the point where we can
outsource the eye candy to the Internet and not bother with 'apps'.
Specifically, just bundle epiphany/webkit into core-image-weston-demo, and
make a nice looking landing page somewhere on yoctoproject.org that links
to various HD video sites and WebGL demonstrators. As long as both GL and
h.264/whatnot are HW accelerated, this should look and feel fine, even in
qemu with virgl and kvm acceleration to a recent x86 CPU family.

For what it's worth, with my mbition.io hat on, I do not care in the
slightest for X anymore, and wouldn't blink an eye if all of it would
disappear from oe-core tomorrow. What I wanted to gauge is whether people
still use X for *new* product development, and for what reasons, and how
much resistance there is to the idea of switching the default graphical
stack in oe-core to weston.

Alex

[-- Attachment #2: Type: text/html, Size: 2213 bytes --]

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

[Richard Purdie]

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

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Tue, Feb 11, 2020 at 05:53:38PM +0000, Richard Purdie wrote:
> 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!

Agreed,

it might be nicer to have x11 separated in some meta-x11 layer and
meta-sato in another layer as well, but as long as there is no clear
replacement and x11 in oe-core doesn't cause too much work I think that
dropping x11 from DISTRO_FEATURES is working quite nicely for people
who don't care about x11 at all already.

Maybe it would make sense to remove x11 from default DISTRO_FEATURES
and/or include opengl+wayland instead?

Cheers,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Tue, 11 Feb 2020 at 18:53, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

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

See my other email I just wrote; I think epiphany/webkit under weston is
able to replace sato more or less fully in this aspect, and actually do
more when it comes to modern embedded UI use cases which involve video and
3D.


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

Certainly no rush here and this transition will proceed carefully and will
take years, but then I am famous for mercilessly removing things from
oe-core, and X with sato would be the biggest one yet! :)

Alex

[-- Attachment #2: Type: text/html, Size: 1502 bytes --]

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

[Adrian Bunk]

On Tue, Feb 11, 2020 at 07:06:57PM +0100, Alexander Kanavin wrote:
> On Tue, 11 Feb 2020 at 18:53, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
> 
> > 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?
> 
> See my other email I just wrote; I think epiphany/webkit under weston is
> able to replace sato more or less fully in this aspect,

Regarding dependencies and buildtime, epiphany/webkit is the largest
part of sato.

If you anyways want core to ship all the multimedia libraries and
ruby and rust and plenty of other packages, then an additional
desktop environment in core would be relatively lightweight.

A small core would be headless.

> and actually do
> more when it comes to modern embedded UI use cases which involve video and
> 3D.
>...

epiphany/webkit is a strange option to support in core for that,
moving Qt back into core instead would bring more usage in actual
products instead of shipping test/demo-only software.

> Alex

cu
Adrian

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 4489 bytes --]

On Tue, 11 Feb 2020 at 18:46, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Tue, 11 Feb 2020 at 16:58, Mark Hatle <mark.hatle@kernel.crashing.org>
> wrote:
>
>>
>> I also don't think oe-core itself needs a 'real' UI, and as my previous
>> response
>> said -- we do need something though to test that the graphical framework
>> is
>> working properly.
>>
>> In the past this often comes back to needing a LOT of a UI in order to
>> adequately test all of the components of the system.   If wayland/weston
>> has a
>> proper test suite that exercises all of the various parts of and pieces
>> of the
>> systems -- then the need for a UI drops considerably.
>>
>> (but we still have the need for some sort of example/demostration...)
>>
>
> Wayland/weston do have test suites, neither of which we currently use. I
> don't know how much they exercise all the moving parts, but the tests do
> exist.
>

I have now ran these tests on my host system to see what they do. Both
wayland and weston tests are fast (a few seconds each), and here's the
outputs for both. I think once these are packaged as ptests and ran on the
AB, all that's left is a reasonable demo UI (which as I said could be
simply epiphany with working HW acceleration).

libwayland:
 1/23 wayland-egl symbols check               OK       0.08 s
 2/23 cpp-compile-test                        OK       0.02 s
 3/23 scanner-test                            OK       0.18 s
 4/23 array-test                              OK       0.02 s
 5/23 client-test                             OK       0.01 s
 6/23 display-test                            OK       0.57 s
 7/23 connection-test                         OK       0.17 s
 8/23 event-loop-test                         OK       0.17 s
 9/23 fixed-test                              OK       0.01 s
10/23 interface-test                          OK       0.01 s
11/23 list-test                               OK       0.01 s
12/23 map-test                                OK       0.01 s
13/23 sanity-test                             OK       4.44 s
14/23 socket-test                             OK       0.02 s
15/23 queue-test                              OK       0.02 s
16/23 signal-test                             OK       0.01 s
17/23 newsignal-test                          OK       0.01 s
18/23 resources-test                          OK       0.01 s
19/23 message-test                            OK       0.01 s
20/23 compositor-introspection-test           OK       0.01 s
21/23 protocol-logger-test                    OK       0.01 s
22/23 headers-test                            OK       0.00 s
23/23 os-wrappers-test                        OK       0.02 s

weston:
 1/26 config-parser                           OK       0.05 s
 2/26 string                                  OK       0.02 s
 3/26 vertex-clip                             OK       0.03 s
 4/26 timespec                                OK       0.05 s
 5/26 zuc                                     OK       0.22 s
 6/26 bad-buffer                              OK       0.12 s
 7/26 devices                                 OK       2.53 s
 8/26 event                                   OK       0.42 s
 9/26 keyboard                                OK       0.23 s
10/26 linux-explicit-synchronization          OK       0.63 s
11/26 internal-screenshot                     OK       0.19 s
12/26 presentation                            OK       0.19 s
13/26 pointer                                 OK       0.53 s
14/26 roles                                   OK       0.18 s
15/26 subsurface                              OK       2.08 s
16/26 subsurface-shot                         OK       0.28 s
17/26 text                                    OK       0.13 s
18/26 touch                                   OK       0.18 s
19/26 viewporter                              OK       2.03 s
20/26 xwayland                                OK       0.48 s
21/26 ivi-shell-app                           FAIL     0.68 s (killed by
signal 6 SIGABRT) (needs some image resources in /usr which I didn't
install)
22/26 plugin-registry                         OK       0.04 s
23/26 surface                                 OK       0.04 s
24/26 surface-global                          OK       0.07 s
25/26 ivi-layout-internal                     OK       0.14 s
26/26 ivi-layout                              OK       0.18 s


Alex

[-- Attachment #2: Type: text/html, Size: 6200 bytes --]