[wpe-webkit] Fate of wpebackend-rd and WpeLauncher
Munez Bn
munezbn.dev at gmail.com
Wed Sep 19 21:05:06 PDT 2018
HI All,
I am new to github and not sure about github pull request procedure.
Appreciate any help
Currently I have pulled buildroot-wpe from igalia
Have created a local development branch ( forked from master)
I have submitted one commit to my local development branch.
I am attaching a git formatted patch along with this mail which i want to
submit.
Able to build liwpe and wpewebkit with these changes. Soon i will add cog
launcher too.
Thanks & Regards
Munez
On Tue, Sep 18, 2018 at 5:26 PM Munez Bn <munezbn.dev at gmail.com> wrote:
>
>
> 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/20180920/a9207f20/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Updated-buildroot-package-files-to-support-following.patch
Type: application/octet-stream
Size: 11405 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20180920/a9207f20/attachment-0001.obj>
More information about the webkit-wpe
mailing list