[wpe-webkit] Fate of wpebackend-rd and WpeLauncher
Adrian Perez de Castro
aperez at igalia.com
Mon Sep 17 06:33:10 PDT 2018
Hello again,
On Mon, 17 Sep 2018 14:23:33 +0530, Munez Bn <munezbn.dev at gmail.com> wrote:
> 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>
> wrote:
>
> > 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.
Exactly.
> > > 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 wayland.
The FDO backend is just a different backend: it is not a supplement, and it
is not a replacement either. There are multiple backends for WPE because
depending on your needs and the target hardware platform you may want to
choose one or another.
Regarding Wayland: remember that “Wayland” itself is just a protocol, and it
does not implement any rendering (that is done by the compositor). The Wayland
protocol allows different processes to share resources typically used by user
interfaces (graphics buffers, input events, and so on) and coordinate with
each other.
The FDO backend uses the Wayland protocol to implement sharing of graphics
buffers between the WPEWebProcess —which does rendering— and the “UI Process”
—which uses the WPE WebKit API, typically the launcher— but nothing else. In
this scenario, the FDO backend makes the WPEWebProcess behave as a Wayland
client which connected to the “UI Process”, and the “UI Process” behaves as a
mini compositor which takes the rendered output from the WPEWebProcess and
provides some API to use the buffers with the frames of rendered content.
This means that the FDO backend does NOT require a “proper” Wayland compositor
like Weston or GNOME Shell running: the backend only provides rendered frames
to the launcher (or application). In the Cog launcher, the platform plug-in
is what actually takes those frames, and displays them. For the moment we
have only a platform plug-in which sends the frames to a Wayland compositor.
Let me try with some ASCII art:
.---------------. Wayland .-----+--------. Wayland .--------.
| WPEWebProcess |<--------->| Cog | plugin |<--------->| Weston |==> SCREEN
'---------------' '-----+--------' '--------'
^^ ^^ ^^ ^^
Wayland Wayland Wayland Wayland
client server client server
Going back to your “Can I use FDO + dispmanx?” question, the answer is: it
should be possible, but nobody has had the time to do it yet. It would be
done by making a Cog platform plug-in which uses Dispmanx directly instead,
so the above diagram would look like this:
.-----+------------.
.---------------. Wayland | | plugin |
| WPEWebProcess |<--------->| Cog | .----------+
'---------------' | | | Dispmanx |==> SCREEN
^^ '-----+-+----------'
Wayland ^^
client Wayland
server
Note how the FDO backend would still use Wayland as protocol to talk between
the WPEWebProcess and Cog processes, but Cog would directly use the Dispmanx
library. This means that you would still need the Wayland libraries installed
in the system, but no Wayland compositor would be involved: the launcher will
handle the video output directly.
> > > 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.
If you run into issues, or have more doubts, please let us know. We'll be
glad to try and help out.
> > > 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.. )
If you want to send pull requests our way in GitHub, or share your patches
by e-mail (for example with “git format-patch”) I can take a look. It would
be great to have more people helping out and contributing :-)
> > 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.
I hope this part is clearer now after I tried to expand a bit above on how
things work when using FDO and what Cog platform plugins are for ;-)
> > > 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.
Ah, I forgot to mention one more thing this in my previous e-mail: you can
avoid the dependency on the FDO backend passing “-DCOG_PLATFORM_FDO=OFF”
to CMake when configuring Cog. It should be possible to use the RDK backend
(Of course you will still need to patch WPEBackend-rdk to compile with
libwpe-1.0.0, as mentioned by Wouter in his e-mail.)
Best regards,
-Adrián
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20180917/1f3116a5/attachment-0001.bin>
More information about the webkit-wpe
mailing list