[wpe-webkit] Fate of wpebackend-rd and WpeLauncher

Munez Bn munezbn.dev at gmail.com
Mon Sep 17 01:53:33 PDT 2018

Hi  Adrián,

Thanks for your reply. Please find my reply below.

On Wed, Sep 12, 2018 at 2:29 AM Adrian Perez de Castro <aperez at igalia.com>

> Hello!
> On Mon, 03 Sep 2018 18:07:38 +0530, Munez Bn <munezbn.dev at gmail.com>
> wrote:
> > Few months back I had started using WPE on raspberry PI and I was able to
> > use the wpebackend-rdk and WPElauncher.
> >
> > But now I see that many things have changed.
> >
> > WPE webkit has official releases and website now.
> > Wpelauncher is going to be deprecated.
> WPELauncher is still using the plain C API, which has *NOT* been available
> since the 2.19.93 release back in May, five months ago. To use WPELauncher
> you would need a snapshot of the WPE WebKit source tree from November 2017,
> and there is no way in which we can responsibly recommend using that: you
> *want* a recent Web engine if you are going to be loading arbitrary content
> from the Internet to avoid being hacked due to old security issues.
> OK so we cant use WPELauncher with latest WpeWebkit.

> > wpebackend is renamed as libwpe
> The functionality implemented in libwpe is basically the same. The rename
> was done to avoid confusion. The old name kind of implied that
> libWPEBackend
> implemented a backend for WPE, which was far from reality: it provides
> interfacing between WPE WebKit and the actual backends (like
> WPEBackend-rdk).
> WPE WebKit 2.22.0 is going to be released in the following days, and it
> needs
> new API in libWPEBackend^W libwpe. It seemed like a good opportunity to do
> the rename *and* the API change at the same time.
> Got it

> > wpebackend-fdo is added (doesn't have much idea on this)
> The idea for the FDO backend is that the backend does not “talk” directly
> to
> the display. Instead, it tries to be generic and provides a mechanism to
> notify the launcher when a frame has been rendered. Then the launcher can
> use the method it prefers to display the frames. In theory it should be
> possible to replace many backends with the FDO one, but not much has been
> done on that front.
> Sorry , I couldnt get it.  Is FDO a replacement for rdk backend or
supplement. And also what if i don't want to use wayland. For example RPI
uses Dispmanx. Can I use FDO + Dispmanx ?
This was possible with wpebackend-rdk where I could use RPI port without
wayland. I also saw there are some BCM ports which uses nexus instead of

> I also see a new WPE launcher COG (Not tried yet)
> Cog is actively maintained, and currently it has good support to use
> Wayland
> compositors to display the frames it gets from the FDO backend.
> Note that there is fallback code in Cog to support old-style backends, and
> it should be able to use Cog with WPEBackend-rdk on the Raspberry Pi with
> the following API-compatible versions of the dependencies:
>   - Cog from the “cog-0.1” branch.
>   - WPE WebKit 2.20.2
>   - WPEBackend 0.2.0 (*not* libwpe).
> You will need to have a “libWPEBackend-default.so” symlink pointing to
> “libWPEBackend-rdk.so” (the same was needed for WPELauncher as well). I
> have
> not tried this setup recently, but it certainly worked fine a couple of
> months
> ago.
> Thanks I will start looking into COG.

> > WebPlatformForEmbedded/buildroot is not active much
> > igalia/buildroot-wpe  overlay is added which doesn't have any launcher
> yet
> > or doesn't work yet.
> We haven't had the time to update the Buildroot repository nor the overlay.
> Looking forward, the overlay will be preferred, because it's cleaner than
> forking Buildroot. I hope that the overlay can be updated after making the
> upcoming WPE WebKit 2.22.0 stable release.
> In the long term, I have plans to try to have the build recipes merged into
> upstream Buildroot, but I don't have an estimation of how much time it will
> take. Sorry.
> Actually I have started using this overlay. It was not installing WPE , I
did some modification ( After referring to old Buildroot WPE) and I was
able to build wpe-webkit. Then I added support for COG in buildroot, but
compilation is failing because of FDO dependencies. I would like to work on
this too and if possible I will contribute in this area.
I want to use wpewebkit with RPI dispmanx from rdk ( I dont want to use
wayland or westores yet.. )

> Looking all this I have some questions now.
> >
> > 1. Is Wpebackend-rdk going to be deprecated or obsoleted ?
> I don't know, but it doesn't need to be. The RDK backend could be updated
> to use the new API in WPE WebKit 2.22.0—and I hope the maintainers of the
> backend will do that at some point, but I cannot speak for them.
> > 2. What is the launcher I should start looking into as WPElauncher is
> > getting deprecated.
> Personally, I would recommend Cog. It is well maintained and it is being
> used
> in a few projects already. If the “cog” launcher does not suit your needs,
> you
> can reuse the “libcogcore” library to write a new one without having to
> implement many things. In particular, if you want to use the FDO backend,
> Cog
> already includes all the Wayland support code as a plugin.
> > 3. wpebackend-fdo is meant for embedded system? Is it running on RPI? Is
> > it just a backend or includes launcher also?
> The FDO backend can be used in embedded systems, yes. Personally, I have
> used
> it on a RaspberryPi3 with the Weston compositor using the Open Source vc4
> driver from Mesa.
> I *think* that technically should be possible to write a Dispmanx platform
> plug-in for Cog, and use the FDO backend directly without needing a Wayland
> compositor. Personally I do not have the time right now, but contributions
> to make this happen would be super welcome!
> > 4. Is COG going to be added to WPE buildroot overlay any soon?
> When I have time to update the overlay after 2.22.0 is released, Cog will
> be
> added to the overlay. It's in my to-do list ;-)
> Like I mentioned above I have added COG and may be I can contribute if
someone can review. But right now the build is failing because of FDO. I
want to use COG with wpebackend-rdk.

> Best regards,
> -Adrián
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20180917/69248a67/attachment.html>

More information about the webkit-wpe mailing list