[wpe-webkit] AArch64 builds in AUR

[Andrea Giammarchi]

P.S. the pop key used in current cog is not valid anymore or it cannot be
imported:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cog

I've also tried to build from cog-git but it cannot find wpe.h ... checking
out cog-2.0 branch works without issues.

I've also made some progress with the package, I just need to re-package it
and see how it works.

https://archlinuxarm.org/forum/viewtopic.php?f=65&t=13469&p=60812#p60812

If you already have libwpe installed, do this in your RPi3:

curl -LO archibold.io/releases/wpewebkit-aarch64-2.22.5.pkg.tar.xz
$ sudo pacman -U wpewebkit-aarch64-2.22.5.pkg.tar.xz

Best Regards



On Sun, Mar 17, 2019 at 2:29 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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/20190318/4133ac8f/attachment-0001.html>