Introducing wpe-webkit-mir-kiosk snap

note that the 20/ channel for the pi kernel has a significantly different initramfs that most likely will not boot successfully on a UC18 device, i.e. I don’t think you can build an UC18 image with a 20/ channel kernel snap…

Yes, I should have prefaced my post with “Assuming the missing driver is the only cause” :pray: @ijohnson That’s what I thought, but didn’t mention. So I would also need to bump the base in my model assertion. Maybe a good trigger to upgrade my two main snaps to core20 bases anyway, so the device doesn’t need to carry three different core snaps …

1 Like

Also please note that UC20 is not yet released although we are very close so YMMV if you try to use the kernel snaps in the 20 channel today. We will have a beta releasing very shortly that would be a great set of verified and tested snaps for you to test with this (i.e. kernel, core20, snapd and pi gadget)

1 Like

Seems like pretty slim use-cases imo. Any specific reason for this preference? Most non-interactive pages are graphical, meant to be seen from far, either images or videos. Perfect example is digital signage.

is there a way we can see which codec it uses to decode videos and whether they are hardware accelerated (something like chrome://media-internals). I am not even able to inspect the page as my chrome doesn’t detect the device.

We’re developing a smart mirror appliance, and most people want to have at least part of their mirror for the actual … you know, “see yourself in the mirror” part without moving imagery :wink: It’s been a while since we put this snap out, and recent WPE releases seem to have improved video stability quite a bit. Also, we’ve since tested our application with WPE for more digital-signage related use cases, and it works quite well.

Chrome won’t help you here, this is a WebKit-based browser. Please refer to #9 in this thread on how to enable and use the remote inspector from any WebKitGTK-based browser. WebKit provides some media-related inspections there, but I’m not aware of something similar to media-internals.

If you want to help out, I have several tests on my todo list that might improve video performance on low-power devices like the Raspberry Pi.

In the hope of reaching users of my snap through this channel: I’d like your feedback on a workaround for a specific issue this snap has had w.r.t. restarts after mir-kiosk refreshes.

(ping @ogra @ijohnson @alan_g @markus @rbaldauf @pachulo)

what’s the issue?

Currently, a refresh of mir-kiosk (which provides the display server for WPE WebKit Mir Kiosk) will cause WPE to vanish from the screen. When mir-kiosk restarts, WPE will log that it lost the Wayland compositor and … do nothing. WPE keeps running, but since the display context goes away intermittently, it won’t be rendered on the new mir context*. I’ve filed this as a probable bug over at the cog launcher repo.

*not 100% sure these are the right terms :upside_down_face:

proposed workaround

Add a daemon/service in the snap that runs once a day (preferably at nighttime) and manually restarts the browser. The included cogctl binary provides a restart command, which in concert with the restart-condition: always will restart the browser – or the helper service could just call snapctl restart on the browser service. Our Core-based device gadget currently restricts snap refreshes to a 3-5am window, so a forced browser restart at 5:15am should minimize the timeframe where WPE is in limbo state after a mir-kiosk refresh.

An issue with a timer-based snap service is that they currently cannot be disabled properly, see How to manage services with sockets/timers - #8 by ijohnson and Launchpad bug.

Any other thoughts or suggestions?

Yes, so far as I know, this dependency between wayland server snap and wayland client snap hasn’t got an elegant solution at present.

Ideally, of course, WPE should fail when mir-kiosk shuts down and restart when it restarts.

You could, perhaps, have a separate process that monitors ${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY:-wayland-0} and, if it disappears and reappears (indicating a mir-kiosk refresh), restarts the WPE server.

i’d agree with alan here, if you do not want to use a brand store (which gives you full update control over all snaps on your devices (i.e. you could hold back mir-kiosk as needed)), just use a watcher script to monitor the socket.

i’d suggest taking a look at inotifywait from the inotify-tools package, that is very helpfull to do such tasks from a shell script …

Less “do not want”, more “cannot afford right now” :wink: But of course, a brand store would be the optimal solution. Thanks for the inotifywait hint, which reminded me that I already had a separate topic on this exact issue over at Wpe-webkit-mir-kiosk restart after `mir-kiosk` refresh - #2 by ogra – whoops, sorry!

That’s a tad more elegant than a forced refresh every day, will check that out. In case the watcher script doesn’t check in during the refresh, can I assume that directory/socket file metadata like timestamps is only updated during a mir-kiosk refresh/restart? (if that makes sense)

Just a note that in the “nearish” future, we will begin work on inter-snap dependencies which amongst other features would allow one service, i.e. WPE, to depend on mir-kiosk, such that if mir-kiosk goes down or stops, then WPE would be stopped as well, and if mir-kiosk is started, then WPE would also be started, etc.

1 Like

Marvelous! Can’t wait for „nearish“ to come closer :smile:

1 Like

As @ogra implies, you can use inotifywait -e delete /run/0/wayland-0 to ensure your script “checks in” when Mir shuts down and something like snapctl restart $SNAP_NAME.daemon to restart.

I just released wpe-webkit-mir-kiosk v2.28.1 on the candidate channel; will bump to stable later today after some additional testing. Notable changes:

  • core20 base
  • vastly improved startup time, since I could drop snapcraft-preload completely :tada:
  • switched from our own wpe-webkit-libs snap to WPE prebuilt deb packages, since focal repos now include the Debian packages which Igalia started publishing in March 2020 [1].
  • Updated WPE to 2.28.x, wpebackend-fdo and libwpe to matching stable versions, cog to 0.6.0
  • added restart-watcher service which uses inotifywait to restart the browser when the Wayland socket at /run/user/0/wayland-0 is deleted; will wait until it reappears. Tested with mir-kiosk refreshes on Raspberry Pi Core devices.

Thanks to @alan_g and @ogra for the inotifywait hints; feedback/improvements on the watcher script are very welcome.

[1] Will ask MOTU maintainers to pull in at least the current bugfix version (2.28.4) for focal. the cog web shell is also available in the repositories, but only at version 0.4.0 – the official release page advises to use 0.6.0 for WPE 2.28.x. So for now, cog will be built from source when snapping wpe-webkit-mir-kiosk.

2 Likes

Hello,
I am using this to run a react kiosk app with ubuntu core. This runs smoothly without glitches so far. Furthermore I am trying to display few phrases in different languages. Any heads up that how I should add language fonts to this if needed?

just ship them with your snap and make sure you use a desktop launcher for your kiosk app that points the font path to them …

If you build a local kiosk app, @ogra’s suggestion is the best solution. If you use WPE as-is and just configure it to point to a web server, you may also embed web fonts for those languages. If a language is only used on specific pages, you can also specify the unicode-range in the @font-face rule to ensure the font only gets loaded if needed. I built this snap for a similar purpose, check out the web font definitions from our app as an example.

1 Like

I have been trying to bind fonts with wpe-webkit-mir-kiosk itself. What I tried was to bind using snapcraft.yaml layout section. I expected it to include fonts in my build machine to snap’s usr/share/fonts. But this attempt was unsuccessful as I cant find any fonts at wpe snap’s space. Any thoughts on this?

this is not how it works. you need to add the font packages you want it to ship as stage-packages: to a part in the snapcraft.yaml then they will end up in $SNAP/usr/share/fonts/…

Sorry for misunderstanding! Now I’m trying to include fonts to the react app itself as @tobias mentioned above. Additionally I’m facing trouble with getting an HDMI sound output from wpe-webkit-mir-kiosk. I found this thread while seeking for help. Any update on this @tobias?

I’m finishing up a snap build with the latest WPE 2.30.2, now based on the gnome-3-34 extension. I expect a load of improvements, and I have added the audio-playback interface, so WPE should spit out sound with the new version. If all goes well, there’ll be a new revision on the edge channel by the weekend. You’re very much invited to test it out :slightly_smiling_face:

2 Likes