Lenovo IdeaPad Slim 3 Chromebook (MediaTek MT8189): Omarchy 4.0.4 from the aarch64 edge packages, status and generic findings

[zoan37]

I've been running Omarchy 4.0.4 from the official aarch64 edge packages as my daily desktop on a MediaTek ARM Chromebook. This isn't a support request. The point is to separate what this hardware needed from what looks like a general Omarchy-on-ARM issue (a non-ACPI, non-Apple, non-Snapdragon machine), in case that helps with aarch64 support.

Port, notes and every file installed on the machine: https://github.com/zoan37/lenovo-slim3-chromebook-omarchy

Device: Lenovo IdeaPad Slim 3 Chromebook (2026), MediaTek Kompanio 540 / MT8189 (4× A78 + 4× A55), Mali-G57 MC2, 8 GB, 1920×1200 eDP. ChromeOS board skywalker, variant quigon. There's no UEFI or MrChromebox for MediaTek Chromebooks, so it boots through ChromeOS's depthcharge in developer mode, with ChromeOS kept on the disk.

What runs

• Packages: Arch Linux ARM plus https://pkgs.omarchy.org/edge/$arch. On aarch64 only edge carries the desktop (omarchy, quickshell, Omarchy's Hyprland build); stable/rc only have apps. All 147 entries of install/omarchy-base.packages resolve on aarch64.
• Install: no ISO and no Limine. I used an ALARM root plus the parts of Omarchy's install scripts that apply. omarchy-provision-user --first-install outside the ISO stops at bundled Node.js tarball missing from /opt/packages. OMARCHY_SETUP_CONTEXT=provision-owner gets past it.
• Session: a systemd autologin unit runs Omarchy's own uwsm start -g -1 -e -D Hyprland hyprland.desktop (the Exec of omarchy.desktop); there's no SDDM. Hyprland 0.56.2 with the Lua config, and the Quickshell shell: bar, panels, launcher, lock screen, notifications, audio/network/Bluetooth/battery/power panels. s2idle suspend and resume work, as do HDMI and USB-C DisplayPort with audio.
• Kernel/GPU: linux-next plus the MT8189 series under review and some local patches. Stock Mesa on Panfrost, no wrappers. (The first version ran on ChromeOS's own kernel with the closed libmali; that worked, but the mainline kernel is simpler.)

Device-specific (nothing for Omarchy to do)

Kernel and device tree, the depthcharge boot setup, an ALSA UCM profile (sent upstream as alsa-ucm-conf#872), HDMI/DP bridge drivers, touchpad palm rejection, and Wi-Fi power management.

Probably generic (Omarchy on ARM / non-ACPI laptops)

Each item has its status on quattro as of 2026-10-10.

1. Battery panel empty. On 4.0.4, omarchy-battery-status picks upower -e | grep BAT. Here UPower calls the smart battery battery_sbs_10_000b, which has no power_now and reports a negative current_now while discharging. Already handled on quattro (/battery_ match, current×voltage, absolute value). Find system batteries not named BAT* #13029 and Fall back to UPower when the sysfs battery rate is implausible #13111 also cover it.
2. Lid state. On 4.0.4, omarchy-hw-laptop-closed reads only /proc/acpi/button/lid. The lid here is SW_LID on cros_ec_buttons. quattro's logind fallback for SW_LID devices should cover it (I haven't tested quattro here).
3. Lid switch bindings never fire. Omarchy binds switch:on:Lid Switch (plus the Apple SMC device name). Under Hyprland 0.56.2's Lua config no switch binding fired on this machine: not Lid Switch, not cros_ec_buttons, not even a uinput device named exactly "Lid Switch". libinput does see the toggles. I can't tell whether that's Hyprland or this setup. I work around it with a small evdev watcher started from autostart.lua that runs the same omarchy-system-lid-close / omarchy-hyprland-monitor-clamshell. Worth checking on other non-ACPI laptops, since lock-on-lid-close depends on it.
4. PATH order in the session. default/hypr/envs.lua puts $OMARCHY_PATH/bin first for everything Hyprland starts (bindings, autostart, the shell), while default/bash/env-bootstrap deliberately prepends it only in dev-link mode. As a result, a /usr/local/bin/omarchy-* override works from a terminal but not from the desktop. /usr/local/bin overrides are the natural place for per-device ports, so I had to call my wrappers by absolute path. Still the case on quattro.
5. Lock-screen wake key. The key that wakes a blanked lock screen ends up in the password field. Wake the lock screen on resume and keep wake keys out of the password #9211 fixes the blanked-panel case (tested on 4.0.4: Wake the lock screen on resume and keep wake keys out of the password #9211 (comment)). A key that wakes the machine from s2idle can still land there, because the EC delivers it after resume.
6. Notifications from autostart. A notify-send from o.exec_on_start(...) at login wasn't shown. As far as I can tell, it runs before the shell has claimed org.freedesktop.Notifications, and nothing is D-Bus-activatable for that name. omarchy-notification-wait handles this, but it's hidden. A line in the autostart docs, or having exec_on_start users wait for the shell, would help anyone adding login notices.
7. Quickshell 0.3.2 from edge breaks re-locking. After the first unlock, lockStateChanged never fires, so every later lock (including lock-before-sleep) silently does nothing (quickshell#1230, LockService reports self-contradictory state: isLocked=true while status shows locked components all false #14588). I pinned Arch Linux ARM's 0.3.1 with IgnorePkg = quickshell. Edge still ships 0.3.2-3. Separately, 0.3.1 crashed once in the audio model when a sink kept failing to start. That's the Quickshell PipeWire reset path (quickshell#1088); Keep PwNode objects out of the audio panel's Repeater models #7783 should make it less likely on the Omarchy side.
8. omarchy-refresh-pacman on 4.0.4 copied the x86 pacman.conf/mirrorlist over Arch Linux ARM's (I added a path-unit guard). Fixed on quattro by the per-platform templates.

I'm happy to test quattro changes for any of these on this machine.

Investigated with help from an AI assistant (Claude).