Introducing wpe-webkit-mir-kiosk snap

[tcfx44]

Still the same. I read somewhere that the WAYLAND_DIPLSAY environment variable may not be set and causing this problem.

[alan_g]

Setting WAYLAND_DISPLAY could cause an issue. Not setting it shouldn’t.

I can’t guess why you would have a problem specific to Server. Sorry.

[lookitscook]

@tobias just tried out this snap on rpi 3b+ and worked great. nice work! I’m working on porting an existing kiosk chrome app to native snap functionality to start targeting Ubunutu (instead of Chrome OS) as my primary recommended platform.

I’d love to use fork your snap as a starting point. Would you consider MIT (or compatible) license for it?

Edit: I attempted to create a merge request to kick things off, but I’m not seeing the option on gitlab. Is reduced visibility turned on for that repo?

[tobias]

@lookitscook sorry for the long delay, the notification got buried in my emails and I was busy with non-snapcraft work for a while

Yes, we’re considering MIT(-compatible) licensing. The only thing I’d ask of you is to contribute back changes which you deem fit for general use. You can have a look at the current issues, for which contributions are especially welcome!

I have enabled merge requests for the repository, so please do open one!

[markus]

Nice and useful snap. How can I troubleshoot why my display (RPI 3b+) goes black after about 24 hours?

[tobias]

Thanks!

For debugging, please check the snap service’s log by running sudo snap logs wpe-webkit-mir-kiosk.browser.

If there are a lot of messages, you may need to retrieve more lines with sudo snap logs -n<number of lines> wpe-webkit-mir-kiosk.browser, try -n200 for a start.

Also, check if mir-kiosk has gotten an update (snap info mir-kiosk → last refresh date). mir-kiosk has to reboot during a snap refresh, which obviously kills the Wayland compositor for WPE. My snap’s service is configured to restart on fatal errors, but WPE doesn’t seem to throw a fatal error if the Wayland context goes away. Without such a signal from the process, the snap service doesn’t restart automatically.

Next stop would be to check if there are fatal JavaScript errors on your page that crash the render thread. You’ll need to snap set either

• devmode=true to access the browser console via Remote Inspector (inspector://<your-rpi-ip-address-or-hostname>:8080 from any WebKit GTK+ browser (see docs)
• error-to-console to log JS errors to the service log, accessible via the snap logs command from above.
  In both cases, the browser has to restart, which will wipe JS error logs, so you’ll need to wait until the error reoccurs.

Hope that helps!

[markus]

Thanks for the quick and elaborate response.

All snap restarts due to settings changes did not bring back the browser screen. The log shows no suspicious entries. Regrettably, I cannot use Remote Inspector since my current workhorse uses Windows (I will try to get something else) and it seems there are no Webkit-based browsers for Windows. The only console error appearing after enabling local logging are “wpe-webkit-mir-kiosk.browser[8114]: realpath: ‘’: No such file or directory”:

I don’t know if I can rule out failing hardware since I cannot switch to another console (the screen stays black but the backlight seems to stay on). I’ll try to get additional devices running and to observe the error.

[alan_g]

@markus a quick way to get more information on where the failure is would be to restart mir-kiosk:

snap restart mir-kiosk

As mir-kiosk restarts you should see an orange “flash” on the screen.

If you don’t see that, then the problem is not wpe-webkit - either the hardware or mir-kiosk is failing.
If you do see that, you know the hardware is working and that mir-kiosk starts.

[tobias]

The realpath: No such file … error also occurs on regular launches; started to occur somewhere after a WPE version bump. Didn’t have the time to investigate yet, but it does not seem to cause any error.

Which version of the snap are you currently using (architecture + revision)? Also, there’s a bug with mount namespaces which is fixed as of 2.42.3, but was initially behind a feature flag. Quickly scanning release notes, I don’t know whether 2.43 enabled the fix by default.

And what @alan_g says

[markus]

@alan_g, thanks for the hint. I’ll try that the next time the screen goes black. When I rebooted the device the console with the cursor showed before the actual reboot. I think this rules out a hardware issue.

[markus]

__@localhost:~$ snap info mir-kiosk
name:      mir-kiosk
summary:   A minimal Mir based shell for kiosk type applications
publisher: Canonical✓
license:   GPL-3.0 OR GPL-2.0
description: |
  A minimal Mir based shell for kiosk type applications
commands:
  - mir-kiosk
services:
  mir-kiosk.daemon: simple, enabled, active
snap-id:      rW4inp7UbJb1YBxWr6SVebxa3Yv7K1Vm
tracking:     stable
refresh-date: 3 days ago, at 13:52 CET
channels:
  stable:    1.7.0-snap93        2020-01-17 (3057) 28MB -
  candidate: 1.7.0-snap93        2020-01-21 (3113) 28MB -
  beta:      ↑
  edge:      1.7.0+dev312-snap93 2020-01-24 (3148) 28MB -
installed:   1.7.0-snap93                   (3057) 28MB -

__@localhost:~$ uname -a
Linux localhost 4.15.0-1054-raspi2 #58-Ubuntu SMP PREEMPT Wed Jan 15 19:28:59 UTC 2020 armv7l armv7l armv7l GNU/Linux

[tobias]

I meant the WPE revision, but I guess you’re using stable/latest

If complete service restarts (i.e. browser restarts) don’t solve the issue, a JS issue isn’t likely. Regarding hardware/mir-kiosk issues: AFAIK, the console cursor isn’t rendered by mir-kiosk, so there might be something else with GPU / modes / related (wildly guessing, out of my depth here). You may restart mir-kiosk right now as well, if the orange flash that @alan_g mentioned appears, then that part is working.

[markus]

Sorry about the confusion. I am using wpe-webkit-mir-kiosk 2.26.2 (latest, stable). It seems it is the restart (attempt) that actually results in the black screen (after the orange flash), I just tried it. I am using the original Raspberry Pi 7" touch screen. The resolution has been set to 800x400.

[alan_g]

@markus

results in the black screen (after the orange flash)

The next thing I’d try is a different kiosk snap - e.g.

snap install --beta mir-kiosk-apps

If that also doesn’t work, then there’s something going wrong with mir-kiosk. (Unlikely, given that we’ve established it starts - but it’s worth checking.)
If mir-kiosk-apps does work, then it’s down to wpe-webkit-mir-kiosk. Maybe try uninstall/reinstall?

[ogra]

@tobias

The realpath: No such file … error also occurs on regular launches; started to occur somewhere after a WPE version bump. Didn’t have the time to investigate yet, but it does not seem to cause any error.

seems to be this:

ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L51

i guess the desktop helpers dont really get enough testing with core based kiosk setups.

is_subpath() seems to be used across them to determine the actual $HOME (which is indeed a bit different in user-less kiosks)

[tobias]

Sweet, thanks! What would be a good condition to test if the snap is running in such a user-less kiosk environment? I’ll open a PR for this.

[markus]

mir-kiosk-apps comes back after restarting mir-kiosk. I un-/reinstalled wpe-webkit-mir-kiosk but the behavior does not improve.

[ogra]

@markus

I un-/reinstalled wpe-webkit-mir-kiosk

make sure to use snap remove --purge ... to be sure the whole $SNAP_DATA is wiped (IIRC snap remove saves a snapshot that it might re-apply during re-install when not using --purge)

[tobias]

Ping @ogra

[markus]

Thanks. This may have fixed it. I purged and reinstalled wpe-webkit-mir-kiosk and the display now worked for four days. It also comes back after stopping and starting the snap.