Re: [WIP] weston 6.0.0 sandbox

[HARUNOBU KUROKAWA <harunobu.kurokawa.dn@xxxxxxxxxxx>]

Hi Daniel, Jan-simon

Ok, I agree if there is no problem because it is small impact.

But I guess that the sandbox seems to take care of only Weston version and wayland-protocol[1], how about other libraries like wayland, in [2] ?


[1] https://git.automotivelinux.org/AGL/meta-agl/commit/?h=sandbox/jsmoeller/weston6&id=ca5d7e3676b20613fdae9ff17748092f6523803f
[2] http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/wayland

Best regards,
Kurokawa.

> -----Original Message-----
> From: automotive-discussions-bounces@xxxxxxxxxxxxxxxxxxxxxxxxx
> <automotive-discussions-bounces@xxxxxxxxxxxxxxxxxxxxxxxxx> On Behalf Of Daniel Stone
> Sent: Wednesday, May 22, 2019 11:28 PM
> To: stephane.desneux@xxxxxxx; Jan-Simon Moeller <jsmoeller@xxxxxxxxxxxxxxxxxxx>
> Cc: AGL ml <automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re:  [WIP] weston 6.0.0 sandbox
> 
> 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
_______________________________________________
automotive-discussions mailing list
automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions