After recently updating the code for my electron-kiosk template snap packaging to base: core20 and the gnome-3-38 extension (the README now also has instructions for working audio output on Ubuntu Core BTW) I wondered if electron would not be ready to actually go wayland-only and drop the X11 layer completely from our kiosk implementation …
So I started with dropping the mir-kiosk-x11 stage snap (along with its command-chain options) and simply adding --enable-features=UseOzonePlatform and --ozone-platform=wayland to the electron launch options.
This did indeed not work 
Chromium uses /dev/shm for internal IPC and while this is allowed to the app snap via the browser-support interface through the apparmor rule:
owner /{dev,run}/shm/{,.}org.chromium.* mrw,
The ubuntu-frame (and mir-kiosk if you prefer old stuff 
) snap actually wants to write to that place as well and is lacking this permission:
apparmor="DENIED" operation="file_receive" profile="snap.mir-kiosk.daemon" name="/dev/shm/.org.chromium.Chromium.Xlmm1z" pid=1114 comm="Mir/Wayland" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
There are a bunch of ways around this:
-
Chromium does have a
--disable-dev-shm-usageoption that electron respects and that disables access to/dev/shmcompletely. While this makes the error go away I’m not sure it is the correct approach (seems this feature was implemented mainly for use in headless container setups )… -
Alternatively
ubuntu-framecould just add thebrowser-supportplug to gain that access, but that grants so much more that it seems like overkill to be added to a display server. -
Adding the line above from the browser-support interface to the end of:
/var/lib/snapd/apparmor/profiles/snap.ubuntu-frame.daemonand calling:
sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.ubuntu-frame.daemon… does also work. So extending the wayland interface with this one-liner might perhaps be feasible.
-
During an internal discussion @ijohnson suggested we might perhaps want to solve that darn
/dev/shmthing once and for all by implementing ashared-memoryinterface in snapd proper …
For the time being I went with option 1. but I guess we eventually want one of the other three options to fix the issue in the longer term.
The next issue I hit was:
electron-kiosk-wayland[1267]: [1267:0922/134411.302682:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
so the app needs a working session dbus … which I do indeed not have on Ubuntu Core inside a daemon snap … seems we need to ship one ourselves then and launch it alongside (or wrapped around) our app …
I added a dbus-launch script:
#! /bin/sh
dbus-run-session --config-file=$SNAP/etc/dbus-1/session.conf -- "$@"
to be used as command-chain script and a session.conf template configuration to a dbus subdir in my project folder and then added the following part to my snapcraft.yaml:
dbus-launch:
plugin: dump
source: dbus
organize:
session.conf: etc/dbus-1/session.conf
dbus-launch: bin/dbus-launch
override-prime: |
snapcraftctl prime
# replace the SNAP_NAME placeholder with our actual project name
sed -i "s/SNAP_NAME/$SNAPCRAFT_PROJECT_NAME/" $SNAPCRAFT_PRIME/etc/dbus-1/session.conf
stage-packages:
- dbus
Now changing the apps: section in my snapcraft.yaml to:
[...]
extensions: [ gnome-3-38 ]
command: usr/bin/wrapper
command-chain:
- bin/dbus-launch
- snap/command-chain/desktop-launch
[...]
makes sure that first the session dbus is brought up, then the desktop-launch script is run to set up font, icon and theme dirs for me and then the electron app is started. This interestingly exposed a minor issue with log spam, that I hope we can quieten eventually.
Now there is a basic electron kiosk template app to be run fully under wayland at:
https://github.com/ogra1/electron-kiosk-wayland
I have done all development and testing on a Pi4 running Ubuntu Core 20 and the latest ubuntu-frame.
Pointing the url= configuration of the snap to youtube and playing 1080p video works smoothly, even though there is no HW acceleration for video decoding with chromium/electron on the Pi (yet), but there are still a bunch of issues left:
- electron requires
--disable-gputo start at all - there are still two errors at startup, they seem to have no actual impact though:
electron-kiosk-wayland[19381]: [19381:0923/145641.523827:ERROR:cursor_loader.cc(115)] Failed to load a platform cursor of type kNull electron-kiosk-wayland[19418]: [19418:0923/145641.646357:ERROR:gpu_init.cc(453)] Passthrough is not supported, GL is swiftshader, ANGLE is - mouse wheel scrolling does not work at all !! (works well under XWayland) … all other mouse functions are fine though.
- Every n’th start electron fails to render at all with:
… and you end up with a white screen (funnily all elements are there and even the mouse pointer changes if you navigate over them, clicking works as well, they are just not visible) … there seems to be a race somewhere that i could not identify yet.electron-kiosk-wayland[19418]: [19418:0923/145641.677879:ERROR:wayland_buffer_manager_gpu.cc(103)] WaylandBufferManagerGpu is not initialized. Can't register a surface.
So while it is possible to run electron as plain wayland client on top of ubuntu-frame today, there is still some mileage to make until it is as rock-solid as the XWayland solution we use today. If you want to help out solving the remaining issues, feel free to fork my code below, build it, tinker with it and find fixes
you can reproduce now?