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

[rafaelguariento]

I Have a Dell Inspiron 7441 with a Snapdragon X plus. When I realized the Linux support on these machines were "close to nothing" I regretted so much of buying the computer with the ARM chip. I just saw in Omarchy News that they will put some effort on Macs with the M chip. Hope this paves the way for Snpadragon machines in the future.

[ggalancs]

On Sunday, September 13, 2026 at 03:12:50 PM GMT+2, Rafael Dettogni Guariento ***@***.***> wrote: I Have a Dell Inspiron 7441 with a Snapdragon X plus. When I realized the Linux support on these machines were "close to nothing" I regretted so much of buying the computer with the ARM chip. I just saw in Omarchy News that they will put some effort on Macs with the M chip. Hope this paves the way for Snpadragon machines in the future. sadly i don't have te hardware to make the changes needed, but I invite you to try to build the image yourself based on the script to build the image, an AI assistant can help you. I will do everything possible to make the process as compatible as possible with your computer. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[rafaelguariento]

I will definitely try to install Omarchy in my Dell Snapdragon. I will try during the week, thanks!

[birkskyum]

We are hard at work on this. More details about ongoing work for snapdragon x elite chips here, including installation steps:

• Snapdragon support - Omarchy on Snapdragon X laptops #11823
• Yoga (also Lenovo) specific - Omarchy on the Lenovo Yoga Slim 7x #10426

[rafaelguariento]

@birkskyum It booted! Full install completed on the Dell Inspiron 14 Plus 7441 (Snapdragon X Plus), and it's running now — WiFi works out of the box too.

Build used your merged omarchy-iso#189 approach in spirit, tested via my local platforms.json workaround (added limine, limine-mkinitcpio-hook, limine-snapper-sync, snapper to the dell-inspiron-7441 entry's packages) combined with omarchy-pkgs#380. Configuring system passed cleanly this time, and the installed system boots and comes up on real hardware — not just a VM, so hopefully this is useful confirmation alongside your own testing.

I'll pull #189 properly onto my checkout and drop the local platforms.json workaround now that the real fix is merged, and let you know if anything else surfaces. Thanks again for all the help working through this!

[rafaelguariento]

[rafaelguariento]

@birkskyum Noticed something else worth flagging: fastfetch on the installed system reports Qualcomm Snapdragon X Elite X1E-80-100 (4) @ 3.42 GHz — but this is a Snapdragon X Plus (Dell's own DMI reports X1P-64-100), and only 4 cores show as active. That may tie back to the psci: failed to boot CPU7 (-22) / CPU11 (-22) messages from my first successful boot — if the device tree in use describes an Elite-class core topology (Omarchy's install/hardware/qualcomm/dtb-uki.sh embeds every matching reference .dtb it finds and lets systemd-stub's DeviceTreeAuto pick one via SMBIOS at boot, since there's no dedicated device tree for this laptop yet), the kernel may be trying to boot cores this Plus chip doesn't actually have fused on.

I'll proceed with that investigation — checking /sys/devices/soc0/*, /proc/device-tree/compatible, dmesg for the psci/devicetree lines, and nproc against the actual expected core count for X1P-64-100 — and report back what I find.

[birkskyum]

Thanks, Rafael! Great to see the Dell installed and running, with Wi-Fi working too. This is useful hardware confirmation that the settings fix and added Limine/Snapper packages work together.

Good catch on the CPU reporting. Checking the actual online CPUs and selected device tree should help establish whether this is just incorrect reporting or a real CPU-startup problem. Your earlier PSCI errors make that worth investigating.

Looking forward to your findings and the retest with the merged ISO change. Thanks for working through this and sharing the details!

[rafaelguariento]

@birkskyum Closing the loop on the device-tree/CPU angle — turns out it's not a bug, and I want to correct my earlier guess.

Ran the Ubuntu live USB check you originally asked for:

$ cat /sys/class/dmi/id/sys_vendor /sys/class/dmi/id/product_name
Dell Inc.
Inspiron 14 Plus 7441
$ tr '\0' '\n' < /sys/firmware/devicetree/base/compatible
dell,inspiron-14-plus-7441
qcom,x1e80100

Then checked the installed Omarchy system. I'd guessed the per-model Dell device tree wouldn't match live-uki.sh/dtb-uki.sh's glob patterns (x1*, hamoa*, glymur*, sc8280xp*) because I assumed the filename would start with dell-. Wrong — the actual naming convention is <soc>-<oem>-<model>.dtb:

$ ls /boot/dtbs/qcom/ | grep -i dell
x1e80100-dell-inspiron-14-plus-7441.dtb
x1e80100-dell-inspiron-14-plus-7441-el2.dtb

That's x1e80100-*, so x1*.dtb catches it fine. The exact per-model device tree is present and being embedded — no glob gap.

So the real explanation for the CPU7/CPU11 psci failures and the "Elite" label:

• Every Windows-on-ARM Snapdragon X laptop's device tree in /boot/dtbs/qcom/ is filed under its SoC platform family (x1e80100-*, x1e78100-*, etc.) regardless of whether the specific unit ships with an Elite or Plus binned chip — same board, same wiring, one shared device tree describing the board's maximum core layout.
• My Dell Inspiron 7441 has a Snapdragon X1P-64-100, a documented 10-core Plus part. nproc reports exactly 10.
• The device tree's cpu-map describes 12 cores (the board's ceiling, matching the Elite-class layout), so PSCI correctly refuses to boot the 2 cores that aren't physically fused on for this binning: psci: failed to boot CPU7 (-22) / CPU11 (-22). 12 − 2 = 10, matching nproc exactly. That's firmware correctly declining non-existent cores, not a driver problem.
• The "Qualcomm Snapdragon X Elite X1E-80-100" label from fastfetch is reading the SoC-family compatible string, which (like the DTB filename) doesn't encode Plus vs. Elite binning. Cosmetic only.

So this resolves the original "three lines then black screen" mystery from my first boot attempt — always a normal PSCI/firmware exchange on a binned chip, never a bug. No code change needed on this front. Thanks again for pointing at the DMI/devicetree comparison — that's what actually nailed it down.

[rafaelguariento]

Backlight control not working (panel-simple-dp-aux, max_brightness=0)

System:

• Dell Inspiron 14 Plus 7441 (Snapdragon X1P-64-100)
• Omarchy 4.0.0.r2120.g66a33c3-1 (edge channel)
• Kernel 7.2.6-1-aarch64-ARCH
• Panel: AUO B140QAX01.H, driven via panel-simple-dp-aux (DisplayPort-AUX, not traditional eDP/PWM)

What happened:
The bar's brightness widget/brightnessctl always reports 0%, and writing to it has no effect — but the physical screen is clearly not at 0% brightness, and the hardware Fn brightness keys still work.

Diagnostics:

$ brightnessctl -l
Device 'dp_aux_backlight' of class 'backlight':
  Current brightness: 0 (0%)
  Max brightness: 0

$ dmesg | grep -i -E "backlight|panel|dp_aux"
[    1.694748] panel-simple-dp-aux aux-aea0000.displayport-controller: Detected AUO B140QAX01.H (0x0ba4)

The kernel registers a dp_aux_backlight sysfs device for this panel, but max_brightness is 0, so there's no usable OS-level brightness range. Brightness is apparently still handled directly by the EC/firmware in response to the Fn keys, bypassing the kernel entirely.

Expected: dp_aux_backlight reports a real max_brightness, and the bar/brightnessctl can read and set brightness through it.

Impact: Cosmetic/inconvenience only — hardware Fn keys still adjust brightness — but there's no software control (bar slider, scripting, auto-dimming on battery, etc.).

Happy to test kernel patches or provide more diagnostics if anyone's working on DP-AUX backlight support for this panel/SoC family.

[rafaelguariento]

Update on the backlight issue above: correcting something I said — the hardware Fn brightness keys do not work either, and they are not an independent EC-level path as I assumed. They go through the exact same broken software path as the bar widget:

XF86MonBrightnessUp   -> omarchy-brightness-display +5%
XF86MonBrightnessDown -> omarchy-brightness-display 5%-

(from /usr/share/omarchy/default/hypr/bindings/media.lua), which calls brightnessctl, which only sees the dp_aux_backlight device with max_brightness: 0. So there is currently no working brightness control at all on this machine, software or hardware-key.

A useful comparison point: Omarchy already ships a fix for an analogous bug on a different platform — /usr/share/omarchy/install/hardware/asus/fix-asus-ptl-display-backlight.sh adds xe.enable_dpcd_backlight=1 to the kernel cmdline for certain ASUS models where the Intel xe driver picks PWM instead of DPCD/AUX backlight control, so writes silently no-op.

Our case looks one level deeper: the panel-simple-dp-aux driver does correctly select the AUX backlight path here (that's literally what dp_aux_backlight is), but the brightness range/scale it reads back from the panel over DPCD comes back empty:

$ cat /sys/class/backlight/dp_aux_backlight/{max_brightness,scale}
0
unknown

So there's no known equivalent one-line kernel parameter fix yet for this SoC/panel combo (AUO B140QAX01.H on the Snapdragon X1P-64-100 msm/Qualcomm display path) — this looks like it needs either a kernel quirk-table entry for this panel, or a look at why the DPCD backlight capability read comes back empty on this platform. Flagging in case this pattern is familiar to anyone who has looked at DP-AUX backlight support on other Snapdragom X laptops.

[birkskyum]

@rafaelguariento Thanks for checking this! Good to have all ten cores confirmed and the DTB question settled.

For the backlight, I found an upstream report for the same Dell 7441 and AUO B140QAX01.H panel, with exactly the same max_brightness=0 symptom. In that case, the panel’s capability data indicated PWM brightness control rather than AUX, so the zero range may not mean an empty or failed capability read.

The author, Avalon Vargas Centeno, reports working brightness adjustment and suspend/resume using a PWM backlight device-tree overlay, and offers to share it. I’d suggest replying to that thread with your findings and asking Avalon for the overlay to test on yours. It’s still experimental, but looks like a concrete starting point, and your results could help move the fix upstream.

[rafaelguariento]

SOLVED: Display brightness control on Dell Inspiron 14 Plus 7441 (Snapdragon X1P-64-100)

Following up on my earlier reports in this thread — brightness control now works, including the Fn keys and the Omarchy bar slider. Full reproduction steps below.

Credit where due: the approach comes from Avalon Vargas Centeno's RFC on dri-devel, and Val Packett's reply in that thread explains why it works.

---

The problem

On this machine the panel (AUO B140QAX01.H) registers a DP-AUX backlight that is unusable:

$ brightnessctl -l
Device 'dp_aux_backlight' of class 'backlight':
	Current brightness: 0 (0%)
	Max brightness: 0

$ cat /sys/class/backlight/dp_aux_backlight/{max_brightness,scale}
0
unknown

max_brightness: 0 means there is no usable brightness range, so every write is a no-op. Note this also breaks the hardware Fn keys — they are not an independent EC path, they just run omarchy-brightness-display → brightnessctl → the same dead device.

Root cause / why the fix works

panel-edp prefers a device-tree-provided backlight and only falls back to AUX when no DT backlight exists. The 7441's device tree defines no backlight node at all, so it lands on the AUX fallback — which this panel/platform doesn't provide a working brightness range for.

A survey of the Snapdragon X device trees shipped in linux-aarch64 makes the pattern clear:

Board	Panel compatible	Backlight in DT
x1e78100-lenovo-thinkpad-t14s	generic edp-panel	pwm-backlight
x1e80100-hp-omnibook-x14	generic edp-panel	pwm-backlight
x1e80100-lenovo-yoga-slim7x	samsung,atna45dc02 (dedicated driver)	none needed
x1e80100-dell-inspiron-14-plus-7441	generic edp-panel	none
x1e80100-dell-latitude-7455	generic edp-panel	none
x1e80100-dell-xps13-9345	generic edp-panel	none

Every board that has working backlight on a generic edp-panel does it with a DT PWM node. The hardware for this is already present on the 7441 — pmk8550_pwm exists in the device tree but ships with status = "disabled", and nothing is wired to it.

The fix is to wire it up the same way the T14s and HP Omnibook do.

---

Reproduction steps

Tested on Omarchy 4.0.0 (edge channel), kernel 7.2.6-1-aarch64-ARCH.

0. Install the device tree compiler

sudo pacman -S dtc     # provides dtc, fdtoverlay, fdtget

1. Write the overlay

Save as dell-7441-pwm-backlight.dtso:

/dts-v1/;
/plugin/;

&pmk8550_pwm {
	status = "okay";
};

&pmk8550_gpios {
	edp_bl_pwm: edp-bl-pwm-state {
		pins = "gpio5";
		function = "func3";
	};
};

&{/} {
	backlight: backlight {
		compatible = "pwm-backlight";
		pwms = <&pmk8550_pwm 0 4266537>;
		brightness-levels = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100>;
		default-brightness-level = <80>;
		power-supply = <&vreg_edp_3p3>;
		pinctrl-names = "default";
		pinctrl-0 = <&edp_bl_pwm>;
	};
};

&{/soc@0/display-subsystem@ae00000/displayport-controller@aea0000/aux-bus/panel} {
	backlight = <&backlight>;
};

Three things it does:

1. enables pmk8550_pwm (ships disabled on this board)
2. adds the edp_bl_pwm pin state — PMK8550 gpio5, func3, the same pin/function the T14s and Omnibook use
3. adds a root pwm-backlight node and points the panel at it

The panel's existing enable-gpios (tlmm gpio74) is deliberately left alone.

⚠️ On the PWM period: 4266537 ns is taken from the ThinkPad T14s device tree. Avalon used the same value, and I see no flicker, but nobody has measured the correct period for the Dell. This is the weakest part of the fix.

2. Compile it

dtc -@ -I dts -O dtb -o dell-7441-pwm-backlight.dtbo dell-7441-pwm-backlight.dtso

3. Apply it to the board's DTB (back it up first)

DTB=/boot/dtbs/qcom/x1e80100-dell-inspiron-14-plus-7441.dtb
sudo cp "$DTB" "$DTB.stock.bak"
sudo fdtoverlay -i "$DTB.stock.bak" -o "$DTB" dell-7441-pwm-backlight.dtbo

# verify
fdtget "$DTB" /backlight compatible     # -> pwm-backlight

4. Rebuild the UKI

Omarchy builds a unified kernel image that embeds the device tree (DeviceTreeAuto= in /etc/kernel/uki.conf), so the DTB change only takes effect after a rebuild:

sudo mkinitcpio -P

5. Reboot and verify

$ brightnessctl -l
Device 'backlight' of class 'backlight':
	Current brightness: 80 (80%)
	Max brightness: 100

$ cat /sys/class/backlight/backlight/scale
linear

dp_aux_backlight disappears entirely — once a DT backlight exists, panel-edp uses it and never reaches the AUX fallback. Fn brightness keys and the Omarchy bar slider both work, with no extra configuration.

---

Making it survive kernel updates

/boot/dtbs/qcom/*.dtb is owned by linux-aarch64, so a kernel upgrade overwrites the patched DTB. A pacman hook re-applies it.

/usr/local/bin/dell-7441-apply-pwm-backlight:

#!/bin/bash
set -euo pipefail

DTB=/boot/dtbs/qcom/x1e80100-dell-inspiron-14-plus-7441.dtb
OVERLAY=/usr/local/share/dell-7441-pwm-backlight/dell-7441-pwm-backlight.dtbo

[[ -f $DTB ]] || { echo "dell-7441-pwm-backlight: $DTB not found, skipping" >&2; exit 0; }
[[ -f $OVERLAY ]] || { echo "dell-7441-pwm-backlight: $OVERLAY missing" >&2; exit 1; }

if fdtget "$DTB" /backlight compatible &>/dev/null; then
  echo "dell-7441-pwm-backlight: overlay already applied"
  exit 0
fi

tmp=$(mktemp)
trap 'rm -f "$tmp"' EXIT
fdtoverlay -i "$DTB" -o "$tmp" "$OVERLAY"
fdtget "$tmp" /backlight compatible >/dev/null
install -m644 "$tmp" "$DTB"
echo "dell-7441-pwm-backlight: overlay applied to $DTB"

/etc/pacman.d/hooks/85-dell-7441-pwm-backlight.hook:

[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = boot/dtbs/qcom/x1e80100-dell-inspiron-14-plus-7441.dtb

[Action]
Description = Re-applying PWM backlight overlay to Dell Inspiron 7441 device tree...
When = PostTransaction
Exec = /usr/local/bin/dell-7441-apply-pwm-backlight

Keep the .dtbo at /usr/local/share/dell-7441-pwm-backlight/. The 85- prefix matters: it sorts before 90-mkinitcpio-install.hook, so the DTB is patched before the new UKI is built.

---

Testing safely first (recommended)

Rather than patching the DTB in place, you can build a throwaway boot entry and keep your working one untouched — this is how I tested it:

sudo mkinitcpio -p linux-aarch64          # regenerate a standalone initramfs

sudo ukify build \
  --linux=/usr/lib/modules/$(uname -r)/vmlinuz \
  --initrd=/boot/initramfs-linux.img \
  --cmdline="$(cat /proc/cmdline)" \
  --devicetree=/path/to/patched.dtb \
  --output=/tmp/test-uki.efi

sudo limine-entry-tool --add-uki pwm-backlight-test /tmp/test-uki.efi

Pick pwm-backlight-test at the Limine menu. If anything goes wrong, reboot and choose your normal entry — nothing about it changed. Remove the test entry afterwards with:

sudo limine-entry-tool --remove-uki pwm-backlight-test

---

Notes for anyone else / upstream

• x1e80100-dell-latitude-7455 and x1e80100-dell-xps13-9345 are in an identical DT configuration (generic edp-panel, no backlight node, pmk8550_pwm disabled). If AUX brightness is broken there too, this is a three-model pattern, not a one-off. If you have one of those machines, please check.
• The PWM period is still unverified for Dell hardware — borrowed from the T14s.
• Proper fix belongs upstream in arch/arm64/boot/dts/qcom/x1e80100-dell-inspiron-14-plus-7441.dts; see the dri-devel RFC linked above.

[rafaelguariento]

Correction to my earlier posts in this thread, with probe-time evidence.

Earlier I wrote that the DPCD backlight capability read "comes back empty" and suggested this might need a kernel quirk entry for this panel. Both of those are wrong, and I can now show why on my own hardware.

Booting the stock device tree with drm.debug=0x106 and dynamic debug on panel-edp.c and drm_dp_helper.c:

panel-simple-dp-aux aux-aea0000.displayport-controller: Detected AUO B140QAX01.H (0x0ba4)
[drm:drm_dp_dpcd_read]       dpu_dp_aux: 0x00700 AUX -> (ret=  5) 05 9b 91 00 00
[drm:drm_dp_dpcd_read]       dpu_dp_aux: 0x00721 AUX -> (ret=  1) 00
[drm:drm_edp_backlight_init] dpu_dp_aux: Found backlight: aux_set=0 aux_enable=0 mode=0

The AUX read succeeds — ret=5, real data, no error. 0x702 = 0x91 advertises PWM brightness control and not AUX brightness setting, so aux_set stays false, drm_edp_backlight_probe_max() returns without populating max, and max_brightness ends up 0.

So the driver is behaving correctly. The panel is telling it, accurately, that it is PWM-controlled. There is no misread, no empty buffer, and nothing here that wants a quirk.

This also retroactively explains a dead end from earlier in this thread: I tested adding regulator-always-on to vreg_edp_3p3, on the theory that the regulator was being power-gated before the capability read. It made no difference — which is exactly what you would expect for a read that was succeeding the whole time.

These bytes are byte-for-byte identical to a capture taken independently on another Dell 7441 by Avalon Vargas Centeno on the dri-devel RFC, whose analysis this confirms — he had inferred this path from reading the source but had not captured the probe-time buffer.

The fix in my step-by-step post above is unaffected and still correct, but the reason it works is better stated as: this panel is PWM-controlled, the board's device tree never described a PWM backlight, and panel-edp prefers a DT-provided backlight over the AUX fallback whenever one exists. It is a missing device-tree description, not a driver bug.

Two practical notes for anyone reproducing this:

• Raw DPCD reads are not possible on the stock Arch Linux ARM kernel — # CONFIG_DRM_DISPLAY_DP_AUX_CHARDEV is not set in /proc/config.gz, so there is no /dev/drm_dp_aux* and no chardev module. The dynamic-debug route above is the workable substitute. Enabling that option in the ALARM kernel would help anyone debugging eDP on these machines. (Corrected: an earlier version of this comment named the symbol CONFIG_DRM_DP_AUX_CHARDEV, which is the older pre-move name and does not exist in current kernels — the DP helpers now live under drivers/gpu/drm/display/.)
• Omarchy boots a UKI, and Limine passes its own kernel command line, which overrides the one embedded in the image when Secure Boot is off. Setting debug options with ukify --cmdline alone silently has no effect; set them on the entry in limine.conf.

Full hardware notes for this machine now live in #12441.