[wpe-webkit] AArch64 builds in AUR

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Mar 20 22:29:15 PDT 2019 

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/c3463b24/attachment-0001.html>

More information about the webkit-wpe mailing list