Apple Silicon Macs and Asahi on Omarchy

Status on 4.0.4

Omarchy does not ship an Apple Silicon build. There is no aarch64 ISO, and the installer is x86_64 only. The Mac support chapter covers Intel Macs and says plainly that installing on an M-series Mac is not directly supported. The Omarchy on… chapter points at Asahi Alarm, which is Arch for M1 and M2 Macs built on Asahi Linux, and links a user-driven guide for layering Omarchy on top.

So everything on this page describes Omarchy running on an Asahi or Arch Linux ARM base, usually through a community fork. The reporters below name theirs: omarchy-mac, omarchy-mac.N builds, and omarchy-mx-mac. None of that is an Omarchy release channel, and none of it gets release testing.

What does work once you are there: the Hyprland session and the Quickshell bar come up, the installer maps the Apple GPU to vulkan-asahi, Wi-Fi associates once the quirk file is gone, and Asahi’s own audio DSP loads and produces sound. What does not work is a long list, and most of it is Omarchy code assuming x86 Linux conventions rather than anything Asahi got wrong.

Forty issues in the tracker match Apple Silicon and Asahi terms. Many of those are Intel Mac reports that share vocabulary, so treat the count as a search result, not a defect list. For Intel Macs with the T2 chip, see /hardware/t2-mac/ instead.

What Omarchy does automatically

Almost nothing, and one thing it should not.

install/hardware/vulkan.sh maps a PCI display controller whose vendor string contains “Apple” to vulkan-asahi. That package is also in install/omarchy-other.packages, and the 3.x to 4.x upgrade path adds it (bin/omarchy-upgrade-to-quattro, plus migration 1784401744.sh). This is the one piece of Apple Silicon support in the released tree, and it works.

The four scripts in install/hardware/apple/ are Intel-Mac code:

• fix-t2.sh gates on PCI IDs 106b:1801 and 106b:1802, the T2 bridge. No M-series Mac has one, so it never runs.
• fix-spi-keyboard.sh and fix-suspend-nvme.sh gate on DMI product_name matching MacBookPro13,x, MacBookPro14,x and friends. M-series Macs identify as MacBookPro18,3, Mac14,10 and the like, which those patterns do not match, so neither runs.
• fix-brcmfmac-supplicant.sh is the problem. It matches sys_vendor starting with “Apple” plus Broadcom IDs including 14e4:4425 and 14e4:4433, which are BCM4378 and BCM4387, the Wi-Fi chips in Apple Silicon Macs. It then writes feature_disable=0x82000 into /etc/modprobe.d/brcmfmac.conf, which is correct for Intel Macs and wrong here.

The omarchy-brightness-display-apple and omarchy-hyprland-monitor-focused-apple commands sound relevant but are not. They drive external Apple Studio Display and Pro Display XDR panels over HID, on any machine.

Known problems

Issue	Models	Status	Fixed in
#7439 Broadcom quirk disables the firmware supplicant on M-series Wi-Fi	Any M1/M2 with BCM4378 or BCM4387	Open. Commit 70e005a5 (2026-08-20) adds an x86_64 gate, but it is not on the quattro default branch or in any released tag through 4.0.4	not yet
#8125 brightness slider and keys no-op	M1 MacBook Pro 13” (apple,j293), likely all	Open. omarchy-hw-display still has no apple-panel-bl entry in 4.0.4	not yet
#7872 audio tuning reports “nothing ships for this laptop” while the Asahi DSP is active	MacBook Pro 16” M1 Max (apple,j316c)	Open, cosmetic but misleading	not yet
#10858 audio dies after resume or a VT switch	MacBook Pro 16” M2 Pro (Mac14,10), MacBook Pro 14” M1 Pro (J314)	Open. maciej-trebacz traced the root cause to PipeWire module teardown, not Omarchy	not yet
#10857 Wi-Fi wedges after lid-close suspend	MacBook Pro 16” 2023, M2 Pro (Mac14,10), BCM4388	Open. The chip gate in the forks’ resume fix omits 14e4:4434	not yet
#8418 lid close does nothing	Asahi MacBooks, confirmed on MacBookPro18,3	Open. Lid state is read from /proc/acpi, which Asahi does not have	not yet
#10477 omarchy-hw-laptop DMI fallback never matches	Any machine without an ACPI lid button	Closed as a duplicate of PR #7948, which is still open. The bug is still in 4.0.4	not yet
#8376 touchpad toggle silently does nothing	MacBook Air M2 2022 (M1 Air unaffected)	Open. Hyprland names the device apple-mtp-multi-touch	not yet
#8946 external HDMI flaps “No Signal” every ~16s while locked	M-series with built-in HDMI	Open. Reporter traced it to apple-dcp upstream	no Omarchy fix
#11914 built-in HDMI link teardown hangs Hyprland	MacBook Pro 16” M1 Pro 2021	Open. flip_done timed out from apple-drm	no Omarchy fix
#8645 and #11591 install menu offers x86-only packages	All aarch64	Open. Nothing in the menu checks architecture	not yet

Two patterns run through that list. The first is hardcoded x86 Linux assumptions: /proc/acpi for the lid, device names containing “touchpad”, backlight device names from Intel and AMD laptops. The second is real Asahi driver limits, mainly apple-dcp display output, which Omarchy cannot fix from userspace.

Fixes that work

Work in this order.

Wi-Fi dead after install. Delete the file the quirk wrote and reload the driver:

sudo rm /etc/modprobe.d/brcmfmac.conf
sudo modprobe -r brcmfmac_wcc brcmfmac && sudo modprobe brcmfmac

thejamescollins confirmed on an M1 Max with BCM4387 that the same access point joins normally once the file is gone, and that reloading in place with modprobe brcmfmac feature_disable=0 connects immediately. bodhiblues, on an M1 Pro, supplied the removal sequence above. The 4.0.0 release is where the quirk widened to every Mac, and migrations/1786391100.sh writes the same file on existing installs, so an update does not clean it up on its own. If the file is there, remove it by hand.

Brightness does nothing. Check which device is real:

brightnessctl -l
brightnessctl -d apple-panel-bl set 10%

If apple-panel-bl visibly dims the screen while the numeric DSI node does not, point Omarchy at it. omarchy-hw-display honours OMARCHY_BACKLIGHT_PATH, so CuraMagis made a directory containing only a symlink to apple-panel-bl and exported that path via hl.env(...) in ~/.config/hypr/hyprland.lua.

Wi-Fi does not come back after suspend. If your chip is BCM4388 (14e4:4434), the fork’s resume fix skips you. doomnote enabled the same omarchy-wifi-resume-fix.service unit by hand and logged the wedge and the recovery: the service reloaded brcmfmac after 12 seconds and NetworkManager reconnected 8 seconds later. That unit is not in the upstream 4.0.4 tree, only in the Mac forks.

Lid close does nothing while docked. flip-in’s fix has three parts: read the lid from logind instead of ACPI, with busctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager LidClosed; swap the $(< file 2>/dev/null) substitution in omarchy-hw-laptop for $(cat file 2>/dev/null) so the DMI fallback actually matches; and re-register the binds against the switch Hyprland reports, which is Apple SMC power/lid events. With all three, a lid close while docked disabled the internal panel and held it.

Audio stuck muted after resume or a VT switch. Restart WirePlumber with systemctl --user restart wireplumber. doomnote runs a resume hook that does exactly that when wpctl status stops answering, and reports it self-heals within about ten seconds. There is no configuration fix, because maciej-trebacz traced the defect to PipeWire destroying the same filter-chain module twice during teardown.

External HDMI. No workaround found. Disabling the lock screen’s blank timer did not stop the flap, and forcing 1080p60 did not stop the hang. Use an external display only if you can tolerate that, or stay on the internal panel.

Install menu entries that fail. On aarch64, entries like Spotify and Dropbox cannot succeed, and the floating terminal prints a green “Done!” regardless of exit status. Check availability first with pacman -Si <pkg>. birkskyum reported on 2026-09-06 that the edge aarch64 package database at pkgs.omarchy.org served 115 packages while stable and rc still returned 404, so some Omarchy-packaged apps do exist for ARM.

Report it

Run omarchy debug --no-sudo --print and paste the output. That command exists in every 4.0.x release. Two reports on this page say it was missing; those machines were on an rc build or a fork build. If yours does not have it, say so and include the manual equivalents.

Always include, because none of it is guessable from a normal Omarchy bundle:

• uname -m and the kernel string, for example 7.1.13-1-1-ARCH.
• The device-tree compatible: cat /proc/device-tree/compatible, which gives you apple,j314s or apple,t6001.
• Which fork and channel you run, and the exact omarchy version output such as 4.0.3.r6962.ga67d7f7-1.
• For audio, the asahi-audio, speakersafetyd, PipeWire and WirePlumber versions.
• For Wi-Fi, lspci -nn | grep -i network so the chip ID is in the report.

File against omacom/omarchy only when the defect is in Omarchy’s own scripts, which is true for the backlight, lid, touchpad and menu bugs. Display and audio-stack failures usually belong upstream with Asahi or PipeWire, and saying so in the report saves everyone a round trip.

Related

• /hardware/t2-mac/ for Intel Macs with the T2 chip, which Omarchy does support
• /hardware/apple-silicon-macs/ for the model page
• /hardware/wifi/ and /hardware/audio/
• /hardware/multi-monitor/ and /hardware/suspend-sleep/
• /fix/no-sound-from-laptop-speakers/
• /hardware/submit/ to add your machine