The Joplin Desktop snap now experimentally supports ARM64

I've recently had a request to release ARM64 builds for Joplin Desktop as a Snap package, following some recent advances in ARM64 hardware enablement on Linux.

As of today, there's an experiment ARM64 snap package for Joplin alongside my regular X64 package. I'm reasonably confident that it works after having some initial feedback, so thought I'd propose this to the world.

Unfortunately I can't test this myself directly, whereas I'd usually test the X64 releases at least manually first; I have to take on blind faith that the ARM64 packages are working (I.E, proven to build, unproven to run/execute). To this extent, they're experimental and might come with issues, so please let me know if you can, and remember, you can revert an update with sudo snap revert joplin-desktop.

But how do you install the ARM64 snap in the first place? Exactly the same way as usual, either graphically via the app store if your distro supports it, or via sudo snap install joplin-desktop, same as X64. The snap client will determine the correct version automatically.

Tl;Dr
Joplin-Desktop snap now has some experimental support for Raspberry Pi's, Chromebooks, and those fancy new Macbooks.

Installed via snap in WSL (win11-arm64), works like a charm. The only thing I'd like is to be able to change the font size of the UI.

@bogorad welcome to the forum.

The easiest way to generally increase the UI font is to use the "Zoom In" feature of the "View" menu. The setting is retained between restarts.

image

Thank you for your suggestion! It solves most of it. The only thing that is still tiny is the 'chrome', but that's not that important.

I noticed fedora-asahi-remix popup in the distributions lately and thought I'd share this:


year of the ARM64 Linux desktop, for sure!

FWIW since announcing this, Github now provides ARM64 runners which along with Canonical's for backup makes the long term production of this viable; so it's not really experimental in the sense of I'll pull it, but it's still worth bearing in mind:

  1. This doesn't get tested manually at all so I'm 100% reliant on users telling me if it somehow passes the build time checks but doesn't even start at runtime whilst somehow the x86_64 build does
  2. So far, no one's ever reported an ARM64 specific bug in this entire time, so that's something.

Hi,

Pop!_OS ARM64 user here, on a UTM virtual machine. Thank you for building an ARM64 version of the Joplin desktop.

I tried to install the snap package : joplin-desktop v3.5.13 from James Carroll✪ installed

However, I have the following error when starting the app:

libpxbackend-1.0.so: cannot open shared object file: No such file or directory
Failed to load module: /home/jerome/snap/joplin-desktop/common/.cache/gio-modules/libgiolibproxy.so
Error org.freedesktop.DBus.Error.Failed: cannot set "default-url-scheme-handler" subproperty "joplin" setting to invalid value "@joplin/app-desktop.desktop"
Sentry: Initialized with autoUploadCrashDumps: false
Gtk-Message: 19:52:57.461: Not loading module "atk-bridge": The functionality is provided by GTK natively. Please try to not load it.

(joplin:16270): Gtk-WARNING **: 19:52:57.706: Theme parsing error: gtk.css:1:0: Failed to import: Erreur lors de l’ouverture du fichier /home/jerome/snap/joplin-desktop/137/.config/gtk-3.0/gtk.css : Permission denied

(joplin:16270): dconf-WARNING **: 19:52:57.752: unable to open named profile (/usr/share/dconf/profile/cosmic): using the null configuration.
[16486:0317/195258.363070:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Error) eglCreateContext: Requested version is not supported
[16486:0317/195258.372817:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Error) eglCreateContext: Requested version is not supported
[16270:0317/195258.545763:ERROR:ui/events/platform/wayland/wayland_event_watcher.cc:47] libwayland: [destroyed object]: error 7: create_immed failed and produced an invalid wl_buffer

Note that libgiolibproxy links to an aarch64 lib:
lrwxrwxrwx 1 jerome jerome 95 mars 17 19:52 libgiolibproxy.so -> /snap/joplin-desktop/137/gnome-platform/usr/lib/aarch64-linux-gnu/gio/modules/libgiolibproxy.so

So I tried Joplin-3.6.3.AppImage .

Executing the image gives me the following error:

Sentry: Initialized with autoUploadCrashDumps: false
[19198:0318/081506.769466:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Error) eglCreateContext: Requested version is not supported
[19198:0318/081506.814330:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Error) eglCreateContext: Requested version is not supported
[19149:0318/081507.140866:ERROR:ui/events/platform/wayland/wayland_event_watcher.cc:47] libwayland: [destroyed object]: error 7: create_immed failed and produced an invalid wl_buffer

I tried to install using Flatpak but it would retrieve only the aarch64 image.

Am I doing something wrong or is the build just not meant to work on Pop!_OS ARM64?

The EGL feedback there suggests it’s more likely an error with Mesa libraries & such, that the (virtual) graphics card (or the drivers powering it) don’t have enough support to get Joplin running in Wayland.

For the snap for example I’d try forcing it to use X11 which might be able to work around that, with e.g.,

XDG_SESSION_TYPE=x11 snap run joplin-desktop

I’m surprised the AppImage runs as I’d have expected an exec format error, looking up UTM virtual machine I'm seeing it's something to do with Macs and maybe there's Apple's Rosetta tooling emulating X86_64 for you?

Regardless, it sounds like setting that environment variable might be the best viable option for all 3 as a short term fix and that the problem is likely Mesa support for the VM or along those lines. I think the snaps bundled Mesa is based on Ubuntu 25.10 and so fairly new.

Chances are then this might happen with other Electron apps that default to Wayland since the changes to do so in Electron 38.2.

Alternatively via UTM on the host you could try to experiment with what methods are available for emulating the GPU to find a GPU that works better by default, casually looking UTM up I can see that there is some flexibility there, and that ideally you might try e.g., the VirGL backend which seems to be the more promising one.

Edit: Also worth trying e.g., LIBGL_ALWAYS_SOFTWARE=true snap run joplin-desktop, hard to tell which I'd recommend if both work. The X11 one might be faster but the CPU emulated GL might be better UX with Wayland being nicer for your display hardware. Similarly this should have similar results in the other packages. There's also a chance the X11 one is both worse and slower :smiley:

Thank you!

XDG_SESSION_TYPE=x11 snap run joplin-desktop

did the trick. I can now experiment with Joplin.