Snapdragon X (x1p42100) aarch64 laptop — is there any path to Omarchy 4, and what would the steps be?

[hawkaii]

I have a Snapdragon X Plus laptop running Hyprland on Ubuntu today, and I'd like to get to Omarchy. I've done a fair bit of digging first so I'm not asking anyone to re-tread ground — summary of what I found is below, then my actual questions at the end.

Hardware

Machine	Lenovo IdeaPad Slim 5x 14Q8X9 (83HL)
SoC	Snapdragon X1P-42-100 (X Plus, 8× Oryon)
GPU	Adreno X1-45 — Mesa 26.0.3, OpenGL 4.6 working
RAM	16 GB
Firmware	UEFI + device tree, no ACPI (/sys/firmware/acpi absent)
Current OS	Ubuntu 26.04, kernel 7.1.7-jg-1-qcom-x1e, DTB lenovo,ideapad-slim5x-lcd
Boot	GRUB + stubble (stubble.dtb_override=false)

Hyprland, audio, Wi-Fi, Bluetooth, suspend and the GPU all work on this kernel today.

What I checked before posting

• pkgs.omarchy.org/stable/x86_64/omarchy.db → 200, .../aarch64/omarchy.db → 404. So the [omarchy] repo has no aarch64 binaries published.
• omarchy-pkgs/build/Dockerfile says "Supports: x86_64 (Arch Linux) and aarch64 (Arch Linux ARM)", and 45 of 112 PKGBUILDs already declare arch=('x86_64' 'aarch64') — so the build plumbing looks like it's there, just not published.
• I can't find a uname -m / x86_64 preflight guard anywhere in the current install scripts, so the installer itself doesn't seem to refuse aarch64 any more.
• There's aarch64-aware hardware code in tree — install/hardware/vulkan.sh maps [Apple]=vulkan-asahi, install/hardware/apple/ has fix scripts, and omarchy-upgrade-to-quattro adds vulkan-asahi.
• Prior art: om-arm-archy ? #803 (closed, not planned), Allow experimental arm64/aarch64 installs in preflight guard #3449 (closed — "We don't have a fully verified setup for arm yet... You can always continue anyway"), Add aarch64 support for Omarchy 3.x #1897 (jondkinney's armarchy, closed unmerged as pre-Quattro, with an invitation to re-propose against the new implementation).
• Everyone I can find actually running Omarchy 4 on aarch64 is on Apple Silicon via Asahi (e.g. No Wi-Fi on Apple Silicon Macs: the Broadcom quirk's chip-ID gate includes BCM4378/BCM4387 #7439: M1 Max, Asahi + ALARM, Omarchy 4.0.0).

Where Snapdragon differs from the Asahi path

The Asahi route works because Asahi did the full distro-integration job: an ALARM port with linux-asahi packaged, Mesa in ALARM's repos. An Asahi user gets their kernel from pacman -Syu.

Snapdragon X has no equivalent. The working kernel for these machines is the jg tree (jglathe / ubuntu-concept), shipped only as Ubuntu .debs. On ALARM you'd be hand-unpacking those, and re-doing it on every kernel bump. As far as I can tell nobody has publicly installed Omarchy on any Snapdragon device — searching this repo for snapdragon, qualcomm, x1e80100, oryon, adreno and dtbloader turns up only #1897.

Questions

1. Is aarch64 currently expected to work on Quattro if you bring your own Arch Linux ARM base, or is Asahi the only shape that's been exercised?
2. Is publishing an aarch64 [omarchy] repo on the roadmap, given the build container already supports it? If not, is building the ~112 packages locally and pointing [omarchy] at a local repo a sane approach, or will something else break first?
3. For a device where the kernel is not packaged for Arch at all, is "ALARM userspace + externally-managed kernel/DTB" something anyone has made survive omarchy-update, or does the update path assume a pacman-managed kernel?
4. @jondkinney — you mentioned at Omacon there might be a clearer path for actual ARM support post-Quattro. Did anything come of that? Happy to be a Snapdragon test case if it's useful.

Happy to file bugs with full detail if I get far enough to hit real ones.

[eniolasonowo]

I am also using a snapdragon cpu and would like to use omarchy. @hawkaii how did you get ubuntu to work ?

[hawkaii]

this repo has all the instruction, he built the kernel and ubuntu image for my device and it has got me a working ubuntu setup

[eniolasonowo]

Thanks very much .

[ggalancs]

There is a path, and most of it is architecture work rather than
machine-specific work — so it should transfer to your Snapdragon, minus the
graphics side.

I built Omarchy 4 (quattro) on Arch Linux ARM aarch64 in a UTM VM on Apple
Silicon, automated end to end:
https://github.com/ggalancs/omarchy-arm-utm — the VM-specific bits are a small,
identifiable minority (virtio modules in mkinitcpio, bootctl --no-variables,
LIBGL_ALWAYS_SOFTWARE=1, a fixed monitor mode, a serial getty), so the aarch64
findings should transfer:

• 121 of the 148 packages in omarchy-base.packages already exist in Arch
  Linux ARM by name (123 if you substitute nvim→neovim and
  ttf-jetbrains-mono-nerd-basic→ttf-jetbrains-mono-nerd). The build computes
  that intersection against the live branch on every run and prints what's
  missing, so you can see exactly where you stand on any aarch64 machine.
• 17 of the remaining 27 build from source. Some needed nothing but adding
  aarch64 to arch=() — a lot of PKGBUILDs declare arch=(x86_64) by
  omission rather than incompatibility, and if it's Rust, Go or portable C++ it
  just builds. Others needed more: OBS had to lose its browser plugin (CEF is
  x86-only) and Pinta needed Microsoft's arm64 .NET runtime. In my run the only
  one I could not get to build was herdr, over a Zig version mismatch.
• Quattro ships as a pacman package, arch=('any'), installing into
  /usr/bin with /usr/share/omarchy alongside. It is not x86_64-only — the
  repository is, which is why you can't install it on ARM. Reproducing its
  layout by hand (the tree, the ~435 commands, profile.d, the uwsm env.d
  drop-in, the SDDM theme) is what makes the desktop come up instead of a bare
  compositor.
• Seal the migrations after installing. A normal install marks them all on
  completion; without that, omarchy-update walks ~80 historical migrations and
  the first one touching an x86-only package stops the update.

What will not transfer: everything I did for virtio-gpu
(LIBGL_ALWAYS_SOFTWARE=1, disabled blur, fixed resolution). On real hardware
with a working GPU driver you should be better off than I am, not worse.

The prepare phase alone might be useful to you as a survey tool: it prints the
list of Omarchy packages with no aarch64 equivalent, computed live.

On your specific question, from what I could verify (2026-08-23)

The Omarchy side is smaller than it looks. Omarchy 4 has no architecture
guard at all — the uname -m check people cite is install/preflight/guard.sh
on master (3.x); on quattro that directory doesn't exist and uname -m
appears zero times in the branch. The blocker is that
stable-mirror.omarchy.org/core/os/aarch64/ returns 404 (x86_64 returns 200)
and install/post-install/pacman.sh points pacman at it. The omarchy package
itself is arch=('any').

The Snapdragon side is where the work is, and it isn't Omarchy's:

• Mainline kernel support is genuinely good now (display, Adreno X1-85, NVMe,
  WiFi/BT, audio, s2idle), and Secure Boot is no longer a blocker.
• But you need a per-model device tree — the firmware's ACPI won't do — and
  the redistributable firmware situation is per-machine. The ThinkPad T14s
  Gen6 has the complete set in linux-firmware; most others need blobs pulled
  out of the Windows partition.
• Arch Linux ARM does not list any Snapdragon X platform — under Qualcomm it
  still only lists the DragonBoard 410c. There's no linux-x1e package to
  install. Arch's own unofficial aarch64 port
  (ports.archlinux.page/aarch64, status
  "Unofficial") does list working devices including the XPS 13 9345 and ThinkPad
  X13s, with bootstrap tarballs from this month — that's probably a better base
  than ALARM for your machine.

So the realistic order is: get Arch aarch64 booting with a working GPU on your
x1p42100 first, and only then worry about Omarchy — which at that point is
mostly git clone plus reproducing what the pacman package would have installed.
I have no reproducible report of Hyprland on Snapdragon X to point you at; Sway
is confirmed working, which is a reasonable smoke test before trying Hyprland.

I wrote the VM side up in more detail here, in case any of the aarch64 legwork
saves you time: #7956