[wpe-webkit] AArch64 builds in AUR

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun Mar 17 06:29:00 PDT 2019 

Sorry for the late reply (I was without my PC/RPi3 this week)

The good news is that somehow I managed to see something ... however, if I
start Weston fullscreen it crashes, every single time.
If I specify width, height of 1280x720 it crashes.
If I say nothing but --socket=wpe and then I cog duckduckgo it shows a
1024x1024 duckduckgo experience, with no mouse showing up whatsoever, but
promising 10FPS on WebGL Aquarium at that resolution and 500 fishes.

The list of ugly bits I've not mentioned yet is here:

   1. cog and cog-git requires wpewebkit ... building that package is a
   lottery. I'd be awesome to have a cog that doesn't strictly need wpewebkit
   and assumes it's already installed
   2. TinyWL builds and shows nothing. A grayish full screen (1080p)
   without duckduckgo in it. I am running from the terminal without any Weston
   session ever started. Not sure how to help debugging this
   3. however, since TinyWL is nowhere in AUR, I prefer using ArchLinux
   bricks so ... Weston is just fine. I'm using a weston.ini and beside the
   resolution gotcha, everything seems to work OK
   4. for some reason, my PC cannot build WPEWebKit anymore. It always
   fails at the last 111 files. I might have messed up something but ...
   bummer.
   5. there is a cairo-git that --enable-gl already, and I might use that
   one, but I believe it should also --enable-glesv2 ... is that correct?

Best Regards



On Tue, Mar 12, 2019 at 10:52 AM Adrian Perez de Castro <aperez at igalia.com>
wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20190317/f2455cdc/attachment.html>

More information about the webkit-wpe mailing list