Re: [WIP] weston 6.0.0 sandbox

[Daniel Stone <daniels@xxxxxxxxxxxxx>]

Hi Stephane,

On Wed, 2019-05-22 at 09:45 +0200, Stephane Desneux wrote:
> There are 2 options here:
> 
> * have weston6 for HH
> * have weston6 for master (for further development)
> 
> Both can be achieved (or not depending on discussion :))

As Jan-Simon says, it would be pretty painful having a split world
between CES and post-CES development. Given the magnitude of the
transition, we want to be able to move sooner rather than later.

> BTW, what are the core reasons to switch to weston6?

We have been doing heavy rework of Weston's API upstream after Weston
5.0. It's not really possible to define a compositor architecture like
the one we have agreed on before Weston 6.0: it would require an AGL-
specific fork of Weston which would then have to be reconciled later
on. Forking Weston completely, seems more difficult than just switching
to a different upstream version.

The changes included a rework of output configuration, exposing the
Weston configuration parser as external API, and many more, which allow
AGL to define its own window management as a user of libweston. It also
adds an extensible debug/tracing infrastructure.

The changes between Weston 5.0 and 6.0 are quite minimal for
backends/BSPs. Whilst 4.0 to 5.0 was a huge change in the backends, 5.0
to 6.0 is much smaller and so should be much easier to port.

Given the above, we decided that the best thing to do was to update to
6.0 early, to avoid diverging between Halibut, the CES demo
(Halibut++), and Icefish.

Cheers,
Daniel

_______________________________________________
automotive-discussions mailing list
automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions