[wpe-webkit] AArch64 builds in AUR

Tue Mar 12 02:52:31 PDT 2019

Hi,

On Thu, 7 Mar 2019 08:55:46 +0100, 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

The MiniBrowser is only built by default for developer builds, and if
you want to compile it as part of a normal build you will need to pass
“-DENABLE_MINIBROWSER=ON” to CMake.

For general use I would recommended a WPE “launcher”, which is how we call
minimal browsers with (almost) no UI. A good option is using Cog, because it
is maintained and some people are already using it in their solutions. There
are PKGBUILDs for it available:

   https://aur.archlinux.org/packages/cog/
   https://aur.archlinux.org/packages/cog-git/

I have pushed updates to mark these two as buildable on AArch64 as well.

> 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?

Done, I think all the needed parts (libwpe, wpebackend-fdo, wpewebkit, and
cog) are now marked as available on aarch64.

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

Once you have Cog built and installed, and a compositor (like Weston)
running, the following should work:

   % WAYLAND_DISPLAY=wpe cog -P fdo https://duckduckgo.com

(Of course, change the value of “WAYLAND_DISPLAY” to the socket name you
have passed to Weston when starting it). If you want a compositor which is
smaller than Weston, a good starting point to build upon would be TinyWL
(which is part of wlroots):

   https://github.com/swaywm/wlroots/tree/master/tinywl

I have successfully used TinyWL with the Cog window in fullscreen mode, with
a command like the following (make sure you are NOT running Weston at the
same time):

   COG_PLATFORM_FDO_VIEW_FULLSCREEN=1 \
       tinywl -s 'cog -P fdo https://duckduckgo.com'

(In this case you don't need to define the “WAYLAND_DISPLAY” environment
variable, because TinyWL already takes care of that.)

Best regards,

-Adrián

> 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
> >>>
> >>
Non-text part: text/html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20190312/1850846b/attachment.bin>