[wpe-webkit] AArch64 builds in AUR

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Mar 20 05:59:00 PDT 2019


wpewebkit-aarch64 landed on AUR
https://aur.archlinux.org/packages/wpewebkit-aarch64/

last doubts in the forum, but basically I have all the pisces to keep
updating/maintaining this module.

My previous questions stands, but I think the current status is
definitively great, compared to not having any pre built wpewbekit at all.

Regards


On Mon, Mar 18, 2019 at 1:59 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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/20190320/85acda75/attachment-0001.html>


More information about the webkit-wpe mailing list