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

[Munez Bn]

On Mon, Sep 17, 2018 at 7:03 PM Adrian Perez de Castro <aperez at igalia.com>
wrote:

> 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.
>
>
Thanks. This is very helpful.


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


> > > > 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 :-)
>
>
Sure. Once I have working changes, I will send pull request or may be send
a patch through mail.


> > > 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 ;-)
>
> Yes thanks :)


> > > > 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.)
>
>
Yes i tried with FDO=OFF and compilation was success. I didn't try
launching yet, I will try today. I need to patch RDK backend also.


>
> Best regards,
>
> -Adrián
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> webkit-wpe mailing list      (webkit-wpe at lists.webkit.org)
> Help/Unsubscribe/Update your Subscription:
> https://lists.webkit.org/mailman//listinfo/webkit-wpe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20180918/ef5edfe9/attachment-0001.html>