[wpe-webkit] AArch64 builds in AUR

[Andrea Giammarchi]

Any help with my previous quest?

On Thu, Mar 7, 2019 at 8:55 AM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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/20190311/39e585ac/attachment.html>