[wpe-webkit] AArch64 builds in AUR
andrea.giammarchi at gmail.com
Wed Mar 6 23:55:46 PST 2019
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
The build produces only a WPEWebDriver binary, but there's no trace of the
`run-minibrowser` as explained in the GitHub page:
I've followed these instructions:
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
> 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
> 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
> 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>
>>> 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
>>> > 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
>>> > that work?
>>> ENABLE_ACCELERATED_2D_CANVAS is disabled by default because it uses
>>> which does not really work as well as you may imagine, and can be slower
>>> some cases depending on many factors (including, but not limited to, the
>>> being used). YMMV.
>>> Note that even with ENABLE_ACCELERATED_2D_CANVAS disabled, WebGL is
>>> 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
>>> > 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
>>>  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,
>>> that it uses the 32-bit Raspberry Pi userland libraries (which cannot be
>>> in 64-bit mode ).
>>> > Thanks again for extra clarifications.
>>> Happy to help :)
>>>  https://github.com/WebPlatformForEmbedded/WPEBackend-rdk
>>>  https://github.com/raspberrypi/userland/issues/314
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-wpe