That sounds very much like the snap refresh namespace issue I mentioned earlier. I’ve noted to check the snapd 2.43 release if the fix for this is already active by default, or still behind an experimental feature flag.
Is showing local files (extending supported schemes to “file://”) planned? I have a case where I want to display the device’s assigned IP and generating a local file with this information and showing it seems like a reasonable approach.
Wasn’t on my schedule yet, but should be doable. Actually, I didn’t test if WPE already loads file:// URLs just fine – in the strictly confined snap environment, we also have to consider where the file is located and how the browser can access it.
For your case, I think the best option would be for your snap to output the local file to the home directory, and then configure WPE to read it from there.
Maybe a good first issue for contributions 
OK, firstly, I would require months of study too even qualify as noob. new to OS, App, and everything in between. Secondly, if this is the wrong place to post this, please direct me and i will be happy to correct. Here is the issue. trying to set up a PI4 just to display a web page in a kiosk mode with no user input required. basically just a digital sign. pi3 and screenly would have been great, but page is too complex and pi3 lacked horsepower. so trying webkit-mir-kiosk. installed core 18, installed snap mir-kiosk and daemonized mir-kiosk . installed snap wpe-webkit-mir-kiosk. (not dev mode as this will be production box eventually) geting black screen and mouse pointer only. Have lots of apparmor=“DENIED” (example: type=1400 audit(1586278024.007:155): apparmor=“DENIED” operation=“rmdir” profile=“snap.wpe-webkit-mir-kiosk.browser” name="/root/snap/wpe-webkit-mir-kiosk/38/" pid=6481 comm=“rmdir” requested_mask=“d” denied_mask=“d” fsuid=0 ouid=0 )
tried to figure out how to resolve by editing profile snap.wpe-webkit-mir-kiosk.browser, or at least put it in warn to confirm this is the issue, but the file is not in /etc/apparmor.d/ or /etc/apparmor.d/local and i don’t know where else to look. ANY advice would be appreciated as I am at a loss.
The pi4 has no working graphics driver yet and XWayland apps on top of mir-kiosk will need this …
it will work fine on pi2 and pi3 though …
FYI, the graphics drivers were enabled in linux-raspi kernel for Focal. As Ubuntu-raspi-5.4.0-1011.11 is the latest tag on the master-next branch, the patch should make it into 5.4.0-1012.12 (presuming the previous naming convention in that repo). Now the only question is when that’ll be released on the 20/stable track, where the current version is 5.4.0-1008.8
If I’m not mistaken, that means I’ll have to bump the kernel in my model assertion to pi-kernel=20, since the pi-kernel=18-pi track will stay at Bionic’s 5.3.x kernel line. Also, I’ll have advise users to re-flash their installations if/once they want to upgrade to a Pi 4 – no complaint here, just thinking aloud to catch misconceptions (kindly pointed out by @ogra 
) before I start this process 
note that there is no promise that enabling the driver is enough, there might be additional pieces missing in the puzzle after this one …
1 Like
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” 
@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 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 
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” 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
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:
-
core20base - vastly improved startup time, since I could drop
snapcraft-preloadcompletely
- 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-watcherservice which uses inotifywait to restart the browser when the Wayland socket at/run/user/0/wayland-0is deleted; will wait until it reappears. Tested withmir-kioskrefreshes 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