[wpe-webkit] AArch64 builds in AUR

[Andrea Giammarchi]

So, it built without issues. I've installed in a folder that I then copied
over the RPi3 and I can `weston --socket=wpe` but then I've no idea how to
test this.

The build produces only a WPEWebDriver binary, but there's no trace of the
`run-minibrowser` as explained in the GitHub page:
https://github.com/WebPlatformForEmbedded/WPEWebKit#running

I've followed these instructions:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=wpewebkit

Anyway, since it builds without issues, do you mind flagging AUR wpewebkit
compatible with aarch64 too, so that when I chroot with my PC I can just
use yaourt (or others) to build it without needing any manual step?

If you have any hint/idea on how to test/use the build, once succeeded,
please share, thank you.





On Wed, Mar 6, 2019 at 11:33 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> Quick update.
>
> I've killed the crickets myself and moved forward
> https://archlinuxarm.org/forum/viewtopic.php?f=65&t=13469#p60732
>
> I have 16GB DDR4 through 6 cores + HT AMD Ryzen taking care of building
> aarch64 via qemu-aarch-static and it seems like it's almost done (2428 out
> of 2698)
>
> It's taking a couple of hours so that's OK, but honestly I think it's
> impossible to build this on an RPi3.
>
> However, since I'm emulating aarch64 right away, it'd be great if you
> could flag wpewebkit target architecture for aarch64 too, so I can simply
> use AUR for everything.
>
> The gotcha with arch-chrooting into aarch64 from x86_64 is that `sudo`,
> which is kinda mandatory for any package operation, doesn't work due
> numerous issues, so that I have to build Yaourt from scratch manually and
> hope it'll manage to handle all packages (as it usually does even if not
> maintained anymore).
>
> *TL;DR* with my PC simulating aarch64 on a Raspberry Pi 3 image, I'm
> confident we can deliver a pre-built wpewebkit to ArchLinuxARM via AUR 🎉
>
> Now, back to the issues I've faced already:
>
>    1. I cannot enable canvas indeed, 'cause cairo-gl is missing. By any
>    chance we understand how Sam Decrock managed to enabled that
>    <https://medium.com/@decrocksam/building-wpe-webkit-for-raspberry-pi-3-cdbd7b5cb362>
>    ?
>    2. is it OK for Igalia if I publish in AUR a pre built binary and
>    maintain it? It means I need some ping, from time to time, when things
>    change
>    3. why wpebackend-fdo-git needs wpebackend-git,  but wpebackend-fdo doesn't
>    ? anything special I should consider if I ever land such package in AUR?
>
> Thanks for your help, patience, and possible outcome 👋
>
>
>
>
> On Wed, Mar 6, 2019 at 1:44 PM Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> Unless the direct backend is notably faster, I think I'm fine with
>> Wayland, also because I believe you need some compositor when you open, as
>> example, the files explorer, so GTK on Weston would be just fine, right?
>>
>> Last question about the canvas:
>>
>> > Note that even with ENABLE_ACCELERATED_2D_CANVAS disabled, WebGL is
>> always rendered by the GPU.
>>
>> One of the demo used in the WPE on Pi post benchmarks the canvas
>> https://smashcat.org/av/canvas_test/ and I've seen it with my eyes it's
>> indeed blazing fast compared to the regular canvas. I don't think it uses
>> WebGL though, so I wonder if I am missing anything.
>>
>> So, how would I force-enable that ?
>>
>>
>>
>> On Wed, Mar 6, 2019 at 1:30 PM Adrian Perez de Castro <aperez at igalia.com>
>> wrote:
>>
>>> Hello Andrea,
>>>
>>> On Wed, 6 Mar 2019 12:38:54 +0100, Andrea Giammarchi <
>>> andrea.giammarchi at gmail.com> wrote:
>>>
>>> > Crickets so far ... btw, I'm going skiing for the Weekend so I'll try
>>> to
>>> > build WPE directly on the Pi.
>>> >
>>> > Everything seems to work fine except ENABLE_ACCELERATED_2D_CANVAS AND
>>> > ENABLE_ENCRYPTED_MEDIA are both OFF, while all others are ON.
>>> >
>>> > I am interested specially in the ENABLE_ACCELERATED_2D_CANVAS, why
>>> wouldn't
>>> > that work?
>>>
>>> ENABLE_ACCELERATED_2D_CANVAS is disabled by default because it uses
>>> Cairo-GL,
>>> which does not really work as well as you may imagine, and can be slower
>>> in
>>> some cases depending on many factors (including, but not limited to, the
>>> GPU
>>> being used). YMMV.
>>>
>>> Note that even with ENABLE_ACCELERATED_2D_CANVAS disabled, WebGL is
>>> always
>>> rendered by the GPU.
>>>
>>> > Also I have another question: is wpebackend preferred over
>>> wpebackend-fdo ?
>>> > Latter seems for Wayland, which I'm OK with, but not sure it performs
>>> any
>>> > better than the former.
>>>
>>> The “wpebackend” package is deprecated and has been replaced by “libwpe”
>>> (the name was confusing, because “wpebackend” was not a backend: it was
>>> just a library used to implement and use backends).
>>>
>>> An alternative WPE backend that works for the Raspberry Pi is the RDK
>>> backend
>>> [1] when built passing “-DUSE_BACKEND_BCM_RPI=ON” to CMake.
>>>
>>> Note that I have not been using the RDK backend myself so I cannot
>>> comment on
>>> its status, and that's the reason why I have not submitted an AUR
>>> package for
>>> it — but should work, with the advantage that a Wayland compositor is not
>>> needed, but with the limitations that only one Web view can be created,
>>> and
>>> that it uses the 32-bit Raspberry Pi userland libraries (which cannot be
>>> built
>>> in 64-bit mode [2]).
>>>
>>> > Thanks again for extra clarifications.
>>>
>>> Happy to help :)
>>>
>>> -Adrián
>>>
>>> ---
>>> [1] https://github.com/WebPlatformForEmbedded/WPEBackend-rdk
>>> [2] https://github.com/raspberrypi/userland/issues/314
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20190307/cb5d30c0/attachment-0001.html>