[wpe-webkit] AArch64 builds in AUR

[Andrea Giammarchi]

In case anyone would like to try, `pacman -U xxx` would install either
cairo-gl or wpewebkit-gl, however the canvas demo has zero performance
improvement over regular wpewebkit, so I am going to try build all the
things via glesv2 instead.

archibold.io/releases/cairo-gl-aarch64-1.17.2.pkg.tar.xz
archibold.io/releases/wpewebkit-gl-aarch64-2.22.5.pkg.tar.xz

Regards

On Thu, Mar 21, 2019 at 6:29 AM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> Yet another update.
>
> I am using XWayland so that I can use xrandr and force/set 1280x720
> resolution.
>
> Using COG_VIEW_FULLSCREEN=1 (can't remember the whole name) does the
> trick, however some demo still reports 1024x1024 resolution, even if I'm
> pretty sure it is actually 1280x720 (no borders, everything centered ...
> must be!)
>
> I believe things are working fine, 'cause I can see this demo at 25fps on
> the Pi3 https://webglsamples.org/dynamic-cubemap/dynamic-cubemap.html
>
> However, the canvas 2D demo goes 8fps, so now I'm building
> cairo-gl-aarch64 and will build wpewebkit-gl-aarch64 too, but I still
> wonder if instead I should use GLESV2 for both builds instead.
>
> In that case I'd go packaging cairo-glesv2-aarch64 and
> wpewebkit-glesvs-aarch64 but I'd like to be sure that's needed.
>
> Youtube doesn't show much ... every video I've tried so far seems to be
> not supported. This might be some missing codec in my ArchLinux thuogh.
>
> Last, but not least, the official LCD touch screen doesn't seem to work at
> all in aarch64 so, since there is no mouse whatsoever in WPE, I'm basically
> incapable of interacting at all with anything shown on the screen: bummer.
>
> Thanks in advance for any sort of help/hint/thoughts.
>
> Best Regards.
>
> On Wed, Mar 20, 2019 at 1:59 PM Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> 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/20190321/cbfa597e/attachment-0001.html>